This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [ping] [PATCH] Different outputs affected by locale
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Thu, 12 Jun 2014 12:36:29 +0100
- Subject: Re: [ping] [PATCH] Different outputs affected by locale
- Authentication-results: sourceware.org; auth=none
- References: <1401192650-29688-1-git-send-email-yao at codesourcery dot com> <538EAEE5 dot 2080708 at codesourcery dot com> <20140604124708 dot GR4289 at adacore dot com> <538F1CC3 dot 9090605 at codesourcery dot com> <87oay8a0t6 dot fsf at fleche dot redhat dot com> <538F803A dot 9020007 at redhat dot com> <538FE412 dot 1050806 at codesourcery dot com> <53903119 dot 6000204 at redhat dot com> <53903EE5 dot 8090107 at codesourcery dot com> <539042A2 dot 4050409 at redhat dot com> <539571C6 dot 40605 at codesourcery dot com> <53958862 dot 5020106 at redhat dot com> <5397BCEC dot 8080300 at codesourcery dot 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