Re: localename on mingw

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: address@hidden
> Date: Fri, 04 May 2018 22:25:55 +0200
> 
> gl_locale_name() is defined, basically (forgive the shorthand notation) as
>   gl_locale_name_thread()
>   || gl_locale_name_posix()
>   || gl_locale_name_default().
> 
> The semantics of your patch was to add specific code for native Windows:
> 
>   gl_locale_name_thread()
>   || gl_locale_name_windows()
>   || gl_locale_name_posix()
>   || gl_locale_name_default().

No, my patch didn't add gl_locale_name_windows.  What it did was make
gl_locale_name_thread do something useful on MS-Windows, instead of
returning NULL.  The main part of the patch is the code added to
gl_locale_name_thread that calls gl_locale_name_from_win32_LCID; all
the rest is just bookkeeping and subroutines needed for making that
call.

> There are three ways to actually implement this:
>   (1) Define a function gl_locale_name_windows, explicitly.
>   (2) Move gl_locale_name_windows() into gl_locale_name_thread().
>   (3) Move gl_locale_name_windows() into gl_locale_name_posix().
> 
> All three options produce the same value for gl_locale_name(), which is
> the only function that is used outside gnulib.
> 
> But the test suite tests gl_locale_name_thread and gl_locale_name_posix
> individually.

Yes, the test suite tests those functions separately.  If only
gl_locale_name is important, then why not remove all the tests for
internal functions?  Faced with that question, my conclusion was that
Gnulib does want those internal functions to serve some useful
purpose, perhaps for future extensions or for Gnulib code other that
gl_locale_name -- and the code in setlocale.c does call some of those
functions separately.  So I preferred to leave the test suite factored
as it was, and instead make sure each one of those functions produced
a meaningful value.

> Pro and cons of (1),(2),(3):
>   Pro (1): Very explicit.
>   Cons (1): Code for a specific platform becomes mentioned in the .h file.
>   Cons (2): gl_locale_name_windows() has nothing to do with threads.
>   Cons (2): Requires some #if in the test suite, around line 480.
>   Pro (3): Both gl_locale_name_windows() and gl_locale_name_posix()
>   are related to setlocale().

Cons (3): gl_locale_name_thread is useless on Windows.
Cons (3): Requires some #if in the test suite.

Your Cons (2) is IMO a weak argument, because the actual problem is
that the order of calling these functions is less useful on MS-Windows
than on Posix platforms, due to unportable assumptions.

> Summary of scores:
>   (1): 0
>   (2): -2
>   (3): +1
> So, option (3) is the best one, for my taste.

I don't see why, see above.

> > I also don't understand why having a thread-level
> > code inside a function whose name ends with "_thread" makes less sense
> 
> AFAICS, the body of gl_locale_name_windows() is not "thread-level code".

Right, so let me rephrase: why having gl_locale_name_thread be useless
on MS-Windows makes more sense than what it does now?  That is my main
problem with your proposal.  Can we instead find a way that leaves
that function useful, and yet solves the problems in the test suite
(which I admit I don't yet understand clearly enough)?

> > And how all that is related to the failures which are the trigger for
> > your proposal?
> 
> 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?  I must be missing something, because I don't think I see
that issue.

Thanks.