Re: [RFC] Allow explicit 16 or 32 char in 'x /s'

Tom Tromey
2010-03-18T22:08:40Z

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre> The patch below allows to
Pierre> print strings that are made of 16 bit or 32 bit char
Pierre> using:
Pierre> 'x /hs ' or 'x /ws ' commands.

It seems like a good idea to me.

Pierre> I tried to enable this feature, keeping it to a minimum:
Pierre> The size modifier is not remembered for /s format,
Pierre> thus any subsequent use of /s alone will still
Pierre> print out byte char strings.

If the user types 'x/2hs' and then 'x/2', does the second invocation
still print wide strings? I think it should.

Pierre> - if (!strcmp (name, "char16_t"))
Pierre> + /* Also recognize the type used by 'x /hs' command. */
Pierre> + if (!strcmp (name, "char16_t")
Pierre> + || (TYPE_CODE (elttype) == TYPE_CODE_INT
Pierre> + && TYPE_LENGTH (elttype) == 2))
Pierre> {
Pierre> result = C_CHAR_16;
Pierre> goto done;
Pierre> }

I am a little concerned that this code can confuse the user.
If sizeof(wchar_t) == 2, then sometimes you could end up printing a
wchar_t using UTF-16 -- which may or may not be appropriate.

I'm not sure how much this matters in practice. However, it seems like
it may be cleaner to override classify_type's decision based directly on
the format character, instead of on the implied type. What do you think
of that? This would also let us introduce a new format character
meaning "wchar_t".

I think the documentation should reflect that the user can't choose the
encoding used here.

Pierre> + The case of strings is handled n decode_format, only explicit

Typo, s/n/in/

Finally, please add some test cases.

Tom