newlocale: Linux incompatibility
Fri Mar 24 13:57:31 GMT 2023
On 3/24/2023 8:18 AM, Corinna Vinschen via Cygwin wrote:
> On Mar 23 22:14, Corinna Vinschen via Cygwin wrote:
>> On Mar 23 15:48, Ken Brown via Cygwin wrote:
>>> Consider the following test case:
>>> $ cat locale_test.c
>>> #include <stdio.h>
>>> #include <locale.h>
>>> int main ()
>>> const char *locale = "en_DE.UTF-8";
>>> locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
>>> if (!loc)
>>> perror ("newlocale");
>>> printf ("newlocale succeeded on invalid locale %s\n", locale);
>>> $ gcc -o locale_test locale_test.c
>>> $ ./locale_test.exe
>>> newlocale succeeded on invalid locale en_DE.UTF-8
>>> On Linux, the newlocale call fails with ENOENT, as is documented on the man
>> Three bugs in fact.
>> First, it's a bug in the Emacs testsuite. The test simply assumes that
>> there's no en_DE locale on any system, but that's just not true.
>> Windows support the RFC 5646 locale "en-DE", which is called "English
>> (Germany)" in the "Region" settings.
>> You can also check with `locale -av | less' and search for en_DE.
>> For the reminder of this mail, I assume you're talking about Cygwin 3.5.
>> I won't fix this for 3.4 anymore, given how much locale handling has
>> changed for 3.5.
>> The second bug is that Cygwin blindly trusts the Windows function
>> ResolveLocaleName(). That function blatantly converts even vaguely
>> similar locales into something it supports. E.g., it converts "en-XY"
>> to "en-US". I. .e., even if you use "en_XY.utf8" as locale, the above
>> testcase will wrongly succeed. So I have to rethink how I resolve POSIX
>> locales to Windows locales.
>> And the third bug is that Cygwin fails to set errno if it doesn't
>> support a locale, but that's a minor inconvenience in comparison.
>> Thanks for the report, I totally missed the above problem with
> I pushed a couple of patches which hopefully clean up the code.
> I had to create a replacement function for ResolveLocaleName which
> doesn't return totally screwy and unexpected results, and special case
> two more locales in /proc/locales output so the output makes sense.
> Oh, and I added error handling to the code so newlocale is now able to
> set errno to ENOENT if the locale is not supported.
> If you want to test this, the changes are in test release
> 3.5.0-0.260.gb5b67a65f87c, which is just building.
That was fast! I can confirm that newlocale now fails with ENOENT on
the invalid locale en_XY.utf8.
More information about the Cygwin