This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Preliminary fix for codecvt_members_unicode_wchar_t
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Paolo Carlini <pcarlini at unitus dot it>
- Cc: Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, libstdc++ at gcc dot gnu dot org
- Date: Mon, 25 Mar 2002 13:38:07 -0800 (PST)
- Subject: Re: [PATCH] Preliminary fix for codecvt_members_unicode_wchar_t
> >However, the test case specifies just "UCS4". Does this always
> >imply big-endian?
> >
> Indeed, this is not all obvious, any UCS4 expert out there?
Sorry for the confusions these test cases have caused. They are all
my fault.
"UCS4" doesn't specify an endianness. UCS4-BE does, and should be used.
%iconv --list
Will show the available transformations on linux. As part of this,
UCS-2, UCS-2BE, UCS-2LE, UCS-4, UCS-4BE,
UCS-4LE, UCS2, UCS4,
So, it looks like UCS4 should be explicitly specified with endianness,
much like the USC-2BE encodings are explicitly specified.
In a way, this confusion in the testcases will hopefully succeed in
explaining to people why these variable-encodings are cool: one big-endian
platforms, one can explicitly do transformations for little-endian
machines, etc. Since network byte order is always big endian, this is
helpful for little-endian machines.
> My plan would be that of testing the outcome of the char fix and then if
> there are no obvious regressions on other platforms, proceed with the
> wchar_t version too.
Sounds great.