Re: [PATCH] Preliminary fix for codecvt_members_unicode_wchar_t

[Paolo Carlini <pcarlini at unitus dot it>]

Ulrich Weigand wrote:

>Well, in this case the *input* to the conversion routine seems to
>suffer from the same problem:
>
Ah! I'm really dumb! Thanks.

>   ext_type        e_lit_base[24] =
>  { 1644167168, 1811939328, 1627389952, 1660944384, 1795162112,  536870912,
>    1879048192, 1694498816, 1627389952, 1912602624, 1811939328, 536870912,
>    1778384896, 1627389952, 1929379840, 1828716544, 1761607680, 1845493760,
>    1694498816, 536870912,  1946157056, 1694498816, 1627389952, 167772160
>  };
>
>
>If I replace this likewise with an explicit bytewise representation
>of big-endian 4-byte integers, the test case succeeds.  Apparently
>the conversion routines fails because UCS4 values with their most
>significant byte non-zero are invalid (if my understanding of the
>encoding is correct).
>
>However, the test case specifies just "UCS4".  Does this always
>imply big-endian?
>
Indeed, this is not all obvious, any UCS4 expert out there?

>Again I'm wondering why the test case succeeds
>on other platforms ...
>
My feeling is that we cannot really say, because we don't have so many 
results for big-endian platforms apart from powerpc and s390. We have 
something about Sparc but we don't know the specific version of the libc 
and possibly _GLIBCPP_USE___ENC_TRAITS may be undefined...

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.

Benjamin?

Ciao, Paolo.