> From: Bruno Haible <br...@clisp.org> > Cc: bug-gnulib@gnu.org > 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.
