Re: localename on mingw

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: address@hidden
> Date: Sat, 05 May 2018 10:27:31 +0200
> 
> > > The test failures occur because the distinction between what happens
> > > in gl_locale_name_thread and gl_locale_name_posix is visible
> > > to the test suite.
> > 
> > Can you elaborate about this distinction and how it is visible in the
> > test suite?
> 
> There were two test failures:
>   - line 158: because in some cases, gl_locale_name() returns a string
>     without charset suffix. One could fix this by using the same logic
>     as in localcharset.c, but I left it as-is because the primary purpose
>     of gl_locale_name() is not the charset suffix.
>   - line 480: The test suite encodes the implication "uselocale() was
>     never called => gl_locale_name_thread() is NULL". Rather than removing
>     this assertion, I preferred to refactor the code so that this assertion
>     holds again.

Those considerations seem less important to me than the functionality
of the code on various platforms.  The functionality should make sense
first and foremost, whereas the test suite structure should IMO be
secondary to that.

> > Cons (3): gl_locale_name_thread is useless on Windows.
> 
> No, this is not a 'Cons (3)'. It is perfectly OK to have a function that
> returns NULL.

It's valid if the notion of a per-thread locale makes no sense.
That's not the situation on Windows.  Returning NULL will require
callers to handle that problematic value specially, thus imposing an
additional burden on developers and providing a window for bugs on
MS-Windows.

> Also look at these descriptions in localename.h:
> 
>   gl_locale_name_thread
>     Determine the current per-thread locale's name, as specified by 
> uselocale()
>     calls.
> 
>   gl_locale_name_posix
>     Determine the thread-independent current locale's name, as specified by
>     setlocale() calls or by environment variables.
> 
> My refactoring made the code on Windows match these descriptions.

But the implementation implicitly assumes that per-thread locale is
more specific than the thread-independent locale.  This assumption is
false on Windows, as long as the "target audience" is ports of Posix
software to Windows, because the thread-local locale is insensitive to
setlocale calls, something Posix programs will not be prepared to deal
with.

So I respectfully submit that your refactoring, while it formally
makes the Windows code more matching the description, is less useful
in practice.