This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Handle cygwin wchar_t specifics
- 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: Fri, 15 Apr 2011 12:15:23 -0600
- Subject: Re: [RFA] Handle cygwin wchar_t specifics
- References: <5928.31498147479$1302882967@news.gmane.org>
>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:
Pierre> because of this, GDB uses "UCS-4LE"
Pierre> for the macro INTERMEDIATE_ENCODING on Cygwin
Pierre> (while "wchar_t" it uses for mingw32, which works well).
Ok, I see the problem. I thought this:
/* If __STDC_ISO_10646__ is defined, then the host wchar_t is UCS-4.
But this is not true! For some values of __STDC_ISO_10646__, a 2 byte
wide character type suffices. In particular, Cygwin's value of 200305
means that it corresponds to Unicode 4.0.0:
http://www.unicode.org/versions/components-4.0.0.html
I think this might be a Cygwin bug, but it is pretty hard to wade
through the ISO / Unicode differences and other assorted standardese to
see. (The reason I think it might be a bug is that Unicode 4.0.0
defines some characters > 0xFFFF.)
Anyway, it doesn't matter if this is a Cygwin bug, since GDB's
assumption here is wrong anyway.
Pierre> The patch below fixes this by
Pierre> explicitly setting the UCS size to two for Windows targets.
I think in the __STDC_ISO_10646__ case, we should just explicitly use
sizeof (wchar_t) somewhere to choose the intermediate encoding. I think
this will be more robust than testing some host define.
Pierre> +#define wchar_size (&(((wchar_t) (0)) + 1) - &((char *) 0))
This doesn't seem to be used.
Tom