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

[Tom Tromey <tromey@redhat.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