Re: [PATCH] Preliminary fix for codecvt_members_unicode_wchar_t

[Paolo Carlini <pcarlini at unitus dot it>]

Benjamin Kosnik wrote:

>>>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.
>
Thanks for your explanations. I'm quite ignorant of all those encodings 
myself :-(

However, there is something which keeps puzzling me. Why in 
config/locale/ieee_1003.1-2001/codecvt_specializations.h there are these 
lines:

    explicit __enc_traits(const locale& __loc)
    : _M_in_desc(0), _M_out_desc(0), _M_ext_bom(0), _M_int_bom(0)
    {
      // __intc_end = whatever we are using internally, which is
      // UCS4 (linux, solaris)
      // UCS2 == UNICODE  (microsoft, java, aix, whatever...)
      // XXX Currently don't know how to get this data from target system...
      strcpy(_M_int_enc, "UCS4");

as if only "UCS4" were supported?!?

How this relates with your observations is not at all clear to me...

>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,
>
I did'nt know about this! Thanks!

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

Ciao, Paolo.