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