🚀 go-pugleaf

Masataka Ohta writes:
> 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.

I never said that we should change 10646 (for wchar_t).


> If C standard want (wchar_t)'c' == 'c'

Wrong. L'c' must be numerically equivalent to 'c'.


> 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?


> If C standard want to incorporate 10646, it may:
> 
> 	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.


> or
> 	2) loosen the requirement of wchar_t  and provide conversion
> 	   functions or macros (such as isascii())

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


> or
> 	3) introduce a new character type (say, is10646char_t :-) )
> 	   whose semantics strictly follows 10646 with appropriate
> 	   conversion functions or macros

Aren't we trying to achieve codeset independence?
-
-- 
Erik M. van der Poel                                      erik@sra.co.jp
Software Research Associates, Inc., Tokyo, Japan     TEL +81-3-3234-2692