Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: wchar_t values
Message-ID: <15650@smoke.brl.mil>
Date: 31 Mar 91 00:34:23 GMT
References: <990@sranha.sra.co.jp> <keld.670360834@dkuugin>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 23

In article <keld.670360834@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes:
>Note that there are problems with this; for all the multibyte
>standard character sets that I know of, L'c' is not equal to 'c' .
>ISO 10646, JIS X 0208, GB 2312 and KSC 5601 all have a value of L'c'
>different from ASCII 'c'. 

In principle this could be handled by the C implementation, which is
NOT obliged to map these characters into any particular code set.

Perhaps a better solution, however, is to all agree not to test for
conformance with the L'c'=='c' criterion, since there seems to be
no good reason for this requirement.  I sure don't remember this
being discussed in X3J11, although it might have been.

>Another problem present in the above is that "the null character"
>shall have the value zero. The NUL character in ISO DIS 10646
>does not have this value, but then the ANSI/ISO C  has different 
>meaning with the term "null character", it means the string terminator
>and does not have a direct relation to the SC2 "NUL character".

Correct -- "null character" is a character (byte) with value zero.
There is no requirement in the C standard that anybody's idea of
"NUL" be represented in the implementation's character set.