Re: localename on mingw

2018-05-05 Thread Bruno Haible
Eli Zaretskii wrote: > 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. In this case, the testsuite pointed to a

Re: localename on mingw

2018-05-05 Thread Eli Zaretskii
> From: Bruno Haible > 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

Re: localename on mingw

2018-05-05 Thread Bruno Haible
Eli Zaretskii wrote: > 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 Correct. These functions are exposed in localename.h. If someone finds them useful, they can use

Re: localename on mingw

2018-05-05 Thread Eli Zaretskii
> From: Bruno Haible > Cc: bug-gnulib@gnu.org > 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

Re: localename on mingw

2018-05-04 Thread Bruno Haible
Hi Eli, > Can you explain the rationale for moving code > between gl_locale_name_thread and gl_locale_name_posix. 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

Re: localename on mingw

2018-05-04 Thread Eli Zaretskii
> From: Bruno Haible > Cc: Eli Zaretskii > Date: Thu, 03 May 2018 05:42:17 +0200 > > On a recent mingw (both 32-bit and 64-bit), I'm seeing this test failure: > > FAIL: test-localename > = > > ../../tests/test-localename.c:158: assertion

Re: localename on mingw

2018-05-03 Thread Bruno Haible
Gisle Vanem asked: > Just curious, which Windows compiler has '__WIN32__' > as a built-in, but not '_WIN32'? Borland C++, according to . When we began gnulib development, Borland C++ was still a reasonable portability target to keep in

Re: localename on mingw

2018-05-03 Thread Gisle Vanem
Bruno Haible wrote: +#if (defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__ + /* On native Windows, here, Just curious, which Windows compiler has '__WIN32__' as a built-in, but not '_WIN32'? AFAICS, all MinGW's have both. And clang-cl does not have '__WIN32__'. -- --gv

localename on mingw

2018-05-02 Thread Bruno Haible
On a recent mingw (both 32-bit and 64-bit), I'm seeing this test failure: FAIL: test-localename = ../../tests/test-localename.c:158: assertion 'strcmp (name, "de_DE.UTF-8") == 0' failed Once this is worked around, there is another one here: /* Check that