On Wed, Aug 7, 2024 at 7:07 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Wed, Aug 7, 2024 at 10:23 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Jeff Davis <pg...@j-davis.com> writes: > > > But there are a couple problems: > > > > > 1. I don't think it's supported on Windows. > > > > Can't help with that, but surely Windows has some thread-safe way. > > It does. It's not exactly the same, instead there is a thing you can > call that puts setlocale() itself into a thread-local mode, but last > time I checked that mode was missing on MinGW so that's a bit of an > obstacle.
Actually the MinGW situation might be better than that these days. I know of three environments where we currently have to keep code working on MinGW: build farm animal fairywren (msys2 compiler toochain), CI's optional "Windows - Server 2019, MinGW64 - Meson" task, and CI's "CompilerWarnings" task, in the "mingw_cross_warning" step (which actually runs on Linux, and uses configure rather than meson). All three environments show that they have _configthreadlocale. So could we could simply require it on Windows? Then it might be possible to write a replacement implementation of uselocale() that does a two-step dance with _configthreadlocale() and setlocale(), restoring both afterwards if they changed. That's what ECPG open-codes already. The NetBSD situation is more vexing. I was trying to find out if someone is working on it and unfortunately it looks like there is a principled stand against adding it: https://mail-index.netbsd.org/tech-userlevel/2015/12/28/msg009546.html https://mail-index.netbsd.org/netbsd-users/2017/02/14/msg019352.html They're right that we really just want to use "C" in some places, and their LC_C_LOCALE is a very useful system-provided value to be able to pass into _l functions. It's a shame it's non-standard, because without it you have to allocate a locale_t for "C" and keep it somewhere to feed to _l functions...
