wchar_t values

Michael Meissner meissner at osf.org
Sat Mar 30 03:00:40 AEST 1991


In article <1991Mar29.073917.1217 at tkou02.enet.dec.com> diamond at jit345.swstokyo.dec.com (Norman Diamond) writes:

| In article <990 at sranha.sra.co.jp> erik at sra.co.jp (Erik M. van der Poel) writes:
| 
| >Which of the following two conditions is the correct interpretation of
| >the ANSI C standard:
| >	('c' == L'c')
| >	('c' == ((char) L'c'))
| 
| Both must be true.  However, if you try it with @ instead of c, or with
| any other character which is not in the basic character set defined in
| section 2.2.1, then all bets are off.
| 
| (Recall that '@' does not even have to compare equal to ((char) '@'), with
| no use of wide characters at all.)

Actually this is not true.  Nowhere in the standard does it say that
the bits for the multibyte character constant 'c' must equal the bits
for the wide character constant L'c'.  As long as mbtowc and wctomb do
the appropriate translations, and that the null byte give all 0's in
wchar_t's, everything is standard conforming.

In fact, if you use Unicode (as opposed to ISO 10646) to hold the
wchar_t's, 'c' will NOT equal L'c'.  Whether this is a reasonable
thing for programmers to expect is immaterial.  My personal bias is
that 'c' should equal L'c'.
--
Michael Meissner	email: meissner at osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?



More information about the Comp.std.c mailing list