🚀 go-pugleaf

Hello!

those who know me have no need of my name wrote:
> 
> <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.

Exactly.

>...  why shouldn't it matter?  because you shouldn't compare a wchar_t to
> anything except a wchar_t.

Exactly. I answered to this matter's question comparing wchar_t to
wchar_t and not anything else - the above message guessed that _wchar_t_
is locale-dependent, and I answered that it's not, it's implementation
dependent only.

> 
> 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.)

No, we were talking _only_ about wchar_t. Again, based on our software
that works on Japanese, Polish (iso-8859-2), Latvian (iso-8859-4), etc.
we see that wchar_t under Sun is always the same Sun's own form.

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

Unfortunately, I did not see any such plans for C compiler.

Also, we are using HP-UX and AIX and I guess they also have their own
implementation of wchar_t - we did not look though, because the fact that
I can not send wchar_t to Java code on our main Unix platform -
Solaris - was enough for us to cancel the original idea and we started
sending 'native', non Unicode data to Java...


-- 
Regards,
Paul Gorodyansky
"Cyrillic (Russian): instructions for Windows and Internet": 
http://ourworld.compuserve.com/homepages/PaulGor/