🚀 go-pugleaf

In article <MEISSNER.91Mar29120040@curley.osf.org> meissner@osf.org (Michael Meissner) writes:
>In article <1991Mar29.073917.1217@tkou02.enet.dec.com> diamond@jit345.swstokyo.dec.com (Norman Diamond) writes:
>> In article <990@sranha.sra.co.jp> erik@sra.co.jp (Erik M. van der Poel) writes:
emvdp>Which of the following two conditions is the correct interpretation of
emvdp>the ANSI C standard:
emvdp>	('c' == L'c')
emvdp>	('c' == ((char) L'c'))
ndd>Both must be true.  However, if you try it with @ instead of c, or with
ndd>any other character which is not in the basic character set defined in
ndd>section 2.2.1, then all bets are off.
ndd>(Recall that '@' does not even have to compare equal to ((char) '@'), with
ndd>no use of wide characters at all.)
mm>Actually this is not true.  Nowhere in the standard does it say that
mm>the bits for the multibyte character constant 'c' must equal the bits
mm>for the wide character constant L'c'.  As long as mbtowc and wctomb do
mm>the appropriate translations, and that the null byte give all 0's in
mm>wchar_t's, everything is standard conforming.

Section 4.1.5, page 99 lines 19-20:
ansi>each member of the basic character set defined in section 2.2.1 shall
ansi>have a code value equal to its value when used as the lone character
ansi>in an integer character constant.

c is in the basic character set defined in section 2.2.1.
L'c' has type wchar_t and must be equal to 'c'.
((char) L'c') must be equal to ((char) 'c'), which in turn must be equal
to 'c' again because c is in the basic character set.
Therefore, both of Mr. van der Poel's propositions are true.
I believe that Mr. Meissner is wrong.

In order to answer the more general case, I gave an example with @ instead
of c.  It is not necessary for '@' to equal L'@' and it is not necessary
for '@' to equal ((char) L'@').  The same non-necessities, of course, apply
to multibyte characters.
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.