Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!sranha!srava!erik From: erik@srava.sra.co.jp (Erik M. van der Poel) Newsgroups: comp.std.c Subject: Re: wchar_t values Message-ID: <1006@sranha.sra.co.jp> Date: 31 Mar 91 04:55:45 GMT References: <990@sranha.sra.co.jp> Sender: news@sranha.sra.co.jp Organization: Software Research Associates, Inc., Japan Lines: 26 Nntp-Posting-Host: srava As several people have guessed, the real reason for bringing up the wchar_t issue is because I am wondering how ISO 10646 can be used in the C language. Personally, I think that we should use it as follows: C ISO DIS 10646/4 wchar_t L'c' 032/032/032/099 000/000/000/099 L'\t' 009/128/128/128 000/000/000/009 I think that this is the most reasonable way to do it since it seems to conform to ANSI C. Of course, this wchar_t encoding does not conform to 10646's processing code, but I do not think that this is important. It is more important for the external code (files, network, etc) to conform to 10646. However, I don't really care what encoding we use for wchar_t, as long as implementors who wish to use 10646 for wchar_t all agree on one encoding. So we should create an international standard the specifies how to use 10646 as a processing code in C. If this spec appears some time after 10646 becomes an IS, implementors might do things differently. So the spec should appear together with 10646. Perhaps in a normative annex in 10646? - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692