Use WCHAR_UNSIGNED when interpreting wide charconsts
Neil Booth
neil@daikokuya.demon.co.uk
Sat Feb 23 15:08:00 GMT 2002
Zack Weinberg wrote:-
> (1) There are a lot of targets that define WCHAR_TYPE as an unsigned
> type without also defining WCHAR_UNSIGNED to 1.
>
> File Line
> 0 osf12.h 31 #define WCHAR_TYPE "short unsigned int"
> 1 arc.h 294 #define WCHAR_TYPE "short unsigned int"
That's cute. How do you get that kind of search?
> It might make sense to figure out some way that WCHAR_UNSIGNED can be
> deduced from WCHAR_TYPE, to avoid this kind of skew. It's not
> as simple as if(strstr(WCHAR_TYPE, "unsigned")), because...
I think a run-time check for consistency of the macros would be good in
a checking-enabled compiler. This test should be enough (see below).
> (2) WCHAR_UNSIGNED and WCHAR_TYPE are target macros; if we use them in
> cpplib, and if some target decides to define them to variable
> quantities, cpp0 won't link. All the existing definitions are 1 or 0,
> but a future port might need it to differ at runtime. There *are*
> runtime-variable definitions of WCHAR_TYPE, although none of them
> change the signedness.
I guess you could say the same for DEFAULT_UNSIGNED_CHAR though, and
that hasn't become a problem yet.
I hope to get cc1 to be the separate preprocessor for 3.2, in which case
the link issue would disappear at least.
Neil.
More information about the Gcc-patches
mailing list