Re: PA glibc nls bug

On 4/22/07, John David Anglin <[email protected]> wrote:
> The x86 result was done on a relatively old system (Suse).  Was
> your x86 test done on a Debian system?

Debian unstable. I sent another email with my details.

> This started as GCC PR 31413:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
>
> The 4.cc test fails because this wchar string isn't being correctly
> processed:
>
>   const wchar_t wstr[] = { 0x897f, 0x5143, L'2', L'0', L'0', L'3',
>                            0x5e74, L'1', L'2', 0x6708, L'1', L'7',
>                            0x65e5 , 0x0 };
>
> Note the first two values are the same as my x86 system returns.

Yes, that means my x86 and hppa debian boxes are broken.

> Paolo said in comment 2 of the PR that all other linux systems are fine.
> However, your x86 results would seem to indicate otherwise.

Yes, my results indicate x86 debian unstable is also broken.

> There does seem to be some assumptions being made about the alignment
> of the pointers.  nl_langinfo_l returns a char * and not a wchar_t *.

What do you think could be the problem?

> The issue is clearly in newlocale.  nl_langinfo_l just returns
> a pointer that was previously setup.

newlocale calls nl_langinfo_l to fill in some structures. So it could
still be a problem with nl_langinfo_l.

Cheersr,
CArlos.