Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.std.c Subject: Re: wchar_t values Message-ID: Date: 29 Mar 91 17:00:40 GMT References: <990@sranha.sra.co.jp> <1991Mar29.073917.1217@tkou02.enet.dec.com> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 31 In-reply-to: diamond@jit345.swstokyo.dec.com's message of 29 Mar 91 07:39:17 GMT 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: | | >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@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?