Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: <78@titccy.cc.titech.ac.jp>
Date: 11 Apr 91 07:14:44 GMT
References: <1107@sranha.sra.co.jp> <71@titccy.cc.titech.ac.jp> <1117@sranha.sra.co.jp>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 30

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

>> If C standard want [L'c' equals 'c'], They can do so simply by ignoring
>> 10646. Currently, C standard has nothing to do with 10646.

>Yes, this is what I've been saying all along. Have you read any of the
>other articles in this thread?

I have been reading the thread and felt the point become fuzzy.

So, I made it clear.

>> 	1) define standard way to convert 10646 to wchar_t

>Yes, this is exactly what I want. Either in an ISO C addendum, or in a
>10646 normative annex, or in a separate International Standard, as
>long as it is published at around the same time as IS 10646.

>Aren't we trying to achieve codeset independence?

How can you be codeset independent by having ISO C addendum about
10646?

>The point is that I don't want to change ANSI/ISO C. Unnecessary
>changes at this late stage may confuse implementors and users.

Why not, if it is necessary?

						Masataka Ohta