This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Allow explicit 16 or 32 char in 'x /s'
- From: Tom Tromey <tromey at redhat dot com>
- To: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: <gdb-patches at sourceware dot org>
- Date: Thu, 18 Mar 2010 16:08:27 -0600
- Subject: Re: [RFC] Allow explicit 16 or 32 char in 'x /s'
- References: <11484.4708740295$1268865815@news.gmane.org>
- Reply-to: tromey at redhat dot com
>>>>> "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