Re: printing 0xbeef wchar_t on x86-windows...

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 15 Oct 2012 12:00:52 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Tom Tromey <tromey@redhat.com>
> 
>     wchar_t single = 0xbeef;
> 
> But with the current HEAD, I get:
> 
>     (gdb) print single
>     $5 = 48879 L'\357'
> 
> In chronological order:
> 
>   * valprint.c:generic_emit_char calls wchar_iterate, and finds
>     one valid character according to the intermediate encoding
>     ("wchar_t"), even though the character isn't valid in the
>     original/target charset ("CP1252").

How would cp1252 enter the picture, when you are talking about a
wchar_t data type?

>     But unfortunately for us, Window's iswprint likes 0xbeef as
>     printable

This happens to be a Unicode codepoint of a Hangul word-constituent
character.  That's what you get for putting random values into wchar_t
data type ;-)

>     But the problem is that convert_between_encodings was called
>     with the width set to 1, instead of using the character type's
>     size.
> 
> With the attached patch, we now get the following output...
> 
>     (gdb) print single
>     $2 = 48879 L'\357\276'
> 
> ... which is no longer missing half of the wide character value.

I guess that's the right output, so long as your output charset does
not support that Hangul character.