Re: Thread-safe nl_langinfo() and localeconv()

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Thomas Munro <thomas.munro@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-28T08:13:54Z
Lists: pgsql-hackers

Attachments

On 27.03.25 11:16, Peter Eisentraut wrote:
>> Patch 0002 also looks okay, except that the error handling could be 
>> unified with existing code, as I had previously pointed out.  Patch 
>> 0005 fixes that.
> 
> I plan to commit this one next, after the above had a bit of time to stew.

also done

>> About patch 0003:
>>
>> I had previously pointed out that the canonicalization might have been 
>> intentional, and that we have canonicalization of ICU locale names.  
>> But we don't have to keep the setlocale()-based locale checking 
>> implementation just for that, I think.  (If this was meant to be a 
>> real feature offered by libc, there should be a 
>> get_locale_name(locale_t) function.)

> Anyway, this patch fails tests on CI on NetBSD, so it will need some 
> further investigation.

It turns out the problem was that nl_langinfo_l() returns a codeset name 
of "646" for the C locale, which we didn't have in our mapping table. 
If we add that, then everything passes there as well.  (But the use of 
nl_langinfo_l() wasn't added by this patch, it just exposes it to the 
tests.  So this is apparently a pre-existing problem.)

Attached are the remaining patches in this series.

Commits

  1. Fix "‘static’ is not at beginning of declaration" warning

  2. Use thread-safe strftime_l() instead of strftime().

  3. Provide thread-safe pg_localeconv_r().

  4. Harmonize MinGW CODESET lookup with MSVC.

  5. Include <xlocale.h> for macOS, take II.

  6. Use thread-safe nl_langinfo_l(), not nl_langinfo().

  7. All POSIX systems have langinfo.h and CODESET.