🚀 go-pugleaf

<3C22320B.E5838283@compuserve.com> divulged:

>So, in our current code - despite the locale - wchar under Sun is always
>the same Sun's own form and under Windows it's UCS-2 - it does not matter
>where our Sun or Windows NT computer is a Japanese or a French one.

in fact it is implementation defined.  which is to say that it's up to the
compiler vendor to decide what they want to do, e.g., if sun feels like
making it ucs-4 when compiling v9 code but a private bastardization
otherwise that is okay as far as the standard is concerned.

in fact the implementor could choose to do it one way in even numbered
threads (or statement-line number!) and another way in odd numbered ones,
so long as they insure that the proper mojo is applied so that it works
consistently, e.g., if thread #1 puts a latin small letter a with macron
(u+0101) into a wchar_t variable, which let's say the implementation stores
using ucs-2 encoding (0x00000101), and thread #2 puts the same letter into
a variable, which let's say is stored using the system (not program) locale
(which is, for the sake of this example, iso-8859-4) if possible otherwise
some sort of encoded value (which detail i will not go into, since it isn't
necessary) which in this case means 0x000000e0, then so long as an
evaluation of var1==var2 results in `true' the implementation works and
should be acceptable.  this would naturally be completely silly, but it
would be allowed, and it shouldn't matter to your code.  why shouldn't it
matter?  because you shouldn't compare a wchar_t to anything except a
wchar_t.

since i/o is usually locale dependent there is a potential for working
programs to fail, e.g., ``env LOCALE=ISO-8859-4 some_program | env
LOCALE=ISO-8859-1 another_program'' may not work as expected if the pipe
passes a u+0101.  (some_program outputs an 0xe0 which another_program
believes is a latin small a with grave.)

all that said, i believe that most implementations will migrate to a ucs or
utf oriented encoding of the storage.  ucs-2 and utf-8 both have strong
arguments -- pro and con -- so which is most likely still a little unclear.

-- 
okay, have a sig then