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

[Pedro Alves <palves at redhat dot com>]

On 06/09/2014 09:35 AM, Yao Qi wrote:

> LC_CTYPE isn't set on the Windows machine I am using.  set LC_CTYPE=C,
> but the output is unchanged.
> 
> I dive into locale stuff, and find something more, in
> main.c:captured_main, gdb does
> 
> #if defined (HAVE_SETLOCALE)
>   setlocale (LC_CTYPE, "");
> #endif
> 
> the man page of setlocale says
> 
> If locale is "", each part of the locale that should be modified is set
> according to the environment variables.
> 
> That is why we can pass env var to change gdb's locale.
> 
> However, looks setlocale on Windows behaves differently when locale is
> "".  The msdn about setlocale
> <http://msdn.microsoft.com/en-us/library/x99tb11d.aspx> says "If locale
> points to an empty string, the locale is the implementation-defined
> native environment.", but it doesn't say much on the
> "implementation-defined native environment".  The following example
> in the same page gives me some hints,
> 
> setlocale( LC_ALL, "" );
> Sets the locale to the default, which is the user-default ANSI code page
> obtained from the operating system.
> 
> As far as I can see, windows doesn't consider any env var with
> setlocale(FOO, "").  

Correct.

> If I am correct, we can't set gdb's locale by means
> of setting env var, 

Not true.  It just means that GDB should be doing more
on native Windows, instead of assuming setlocale on Windows
behaves like the POSIX counterpart.  See e.g.,
src/intl/localename.c  (gettext):

...
  /* Let the user override the system settings through environment
     variables, as on POSIX systems.  */
  retval = getenv ("LC_ALL");
  if (retval != NULL && retval[0] != '\0')
    return retval;
  retval = getenv (categoryname);
  if (retval != NULL && retval[0] != '\0')
    return retval;
  retval = getenv ("LANG");
  if (retval != NULL && retval[0] != '\0')
    return retval;

  /* Use native Win32 API locale ID.  */
  lcid = GetThreadLocale ();
...

etc.

But that code has evolved upstream, and we have the solution
already in gnulib.  See:

http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00154.html

Newer versions of intl/gettext override setlocale like that too:

 http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/setlocale.c

> instead, we have to match all the possibilities in
> the testcase.  WDYT?

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.

-- 
Pedro Alves