Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!know!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.c
Subject: Re: wchar_t values
Message-ID: <71@titccy.cc.titech.ac.jp>
Date: 10 Apr 91 12:11:29 GMT
References: <15651@smoke.brl.mil> <keld.670719584@dkuugin> <HARKCOM.91Apr5091146@spinach.pa.yokogawa.co.jp> <1107@sranha.sra.co.jp>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 25

In article <1107@sranha.sra.co.jp>
	erik@srava.sra.co.jp (Erik M. van der Poel) writes:

>Keld is referring to the problem that I brought up in the first
>article in this thread. I.e. 10646 'c' does not have the same numeric
>value as ASCII 'c'.

It is very strange that international character code standard is affected
by C standard.

If C standard want (wchar_t)'c' == 'c', They can do so simply by ignoring
10646. Currently, C standard has nothing to do with 10646.

If C standard want to incorporate 10646, it may:

	1) define standard way to convert 10646 to wchar_t
or
	2) loosen the requirement of wchar_t  and provide conversion
	   functions or macros (such as isascii())
or
	3) introduce a new character type (say, is10646char_t :-) )
	   whose semantics strictly follows 10646 with appropriate
	   conversion functions or macros

							Masataka Ohta