Re: [ping] [PATCH] Different outputs affected by locale

[Pedro Alves <palves@redhat.com>]

On 06/11/2014 03:20 AM, Yao Qi wrote:
> On 06/09/2014 06:11 PM, Pedro Alves wrote:
>> I think the test caught a real GDB bug on Windows, and we
>> should fix GDB to make it look at the environment variables,
>> as is expected of GNU programs.  And that the best way
>> to handle this is to import the gnulib setlocale module.
> 
> I've started setlocale module import, but during the work, I did some
> experiments and the result is confusing me.
> 
> We import setlocale so that we can set locale through env var, assuming
> that different locales affect the return value of iswprint (0xa2).
> However, this assumption isn't true on Windows :(

Well, it actually is.

> 
> I write the following program to check the return value of iswprint
> under different locales.
> 
> On Linux, the output is reasonable
> $ ./iswprint
> 4
> C: 0
> en_US.UTF-8: 1
> C: 0
> 
> On Windows, iswprint always return true!
> C:\>iswprint.win.exe
> 2
> C: 16
> English_United States.1252: 16

This shows that what happens is that on Windows the LC_CTYPE=C picks
up the CP-1252 Windows code page (Latin 1), an extended ASCII
code page.  And in that code page, 162 is printable.

> C: 16
> 
> iswprint return value depends on LC_CTYPE, but under LC_CTYPE=C,
> iswprint (0xa2) behaves differently on Windows and Linux.
> 

The difference is really in what locale/code page LC_CTYPE=C picks
up.

What does "show host-charset" show on Windows, before and after
you make GDB pick LC_CTYPE=C from the environment (with the
setlocale gnulib module)?

(Ideally, the wchar tests would actually iterate testing GDB
behaves as expected with different values of LC_CTYPE, etc. set
in the environment.  With all other tests assuming ASCII as set
by default by the testsuite framework.)

-- 
Pedro Alves