This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: printing 0xbeef wchar_t on x86-windows...
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org, tromey at redhat dot com
- Date: Mon, 15 Oct 2012 21:46:27 +0200
- Subject: Re: printing 0xbeef wchar_t on x86-windows...
- References: <20121015190052.GH3034@adacore.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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.