is... functions (e.g.
ctype.h aren't entirely predictable. They take
int arguments but expect character values in the
unsigned char range, so on a platform where
char is signed, passing a
char value directly could lead to undesirable sign extension. I believe that the typical approach to handling this is to explicitly cast to an
unsigned char first.
Okay, but what is the proper, portable way to deal with the various
isw... functions in
char, also may be signed or unsigned, but because
wchar_t is itself a
typedef, a typename of
unsigned wchar_t is illegal.
Upon re-reading the ISO C99 specification regarding
wctype.h, it states:
For all functions described in this subclause that accept an argument of type
wint_t, the value shall be representable as a
wchar_tor shall equal the value of the macro
WEOF. If this argument has any other value, the behavior is undefined. (§7.25.1/5)
Contrast this with the corresponding note for
In all cases the argument is an
int, the value of which shall be representable as an
unsigned charor shall equal the value of the macro
EOF. If the argument has any other value, the behavior is undefined. (§7.4/1)
I think that it's also worth understanding the motivation for why the
ctype.h functions require
unsigned char representations. The standard requires that
EOF be a negative
int (§7.19.1/3), so the
ctype.h functions use
unsigned char representations to (try to) avoid potential ambiguity.
In contrast, that motivation doesn't exist for
wctype.h functions. The standard makes no such requirement of
WEOF, elaborated by footnote 270:
The value of the macro
WEOFmay differ from that of
EOFand need not be negative.
WEOF is already guaranteed to not conflict with any character represented by
wctype.h functions don't have or need any of the unsigned nonsense, and
wchar_t values can be passed to them directly.