On Mon, Apr 17, 2023 at 8:00 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Sun, Dec 18, 2022 at 10:27 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > > With my garbage collector hat on, that made me wonder if there was > > some more potential cleanup here: could we require locale_t yet? The > > last straggler systems on our target OS list to add the POSIX locale_t > > stuff were Solaris 11.4 (2018) and OpenBSD 6.2 (2018). Apparently > > it's still too soon: we have two EOL'd OSes in the farm that are older > > than that. But here's an interesting fact about wrasse, assuming its > > host is gcc211: it looks like it can't even apply further OS updates > > because the hardware[1] is so old that Solaris doesn't support it > > anymore[2]. > > For the record, now the OpenBSD machines have been upgraded, so now > "wrasse" is the last relevant computer on earth with no POSIX > locale_t. Unfortunately there is no reason to think it's going to go > away soon, so I'm just noting this fact here as a reminder for when it > eventually does...
Since talk of server threads erupted again, I just wanted to note that this system locale API stuff would be on the long list of micro-obstacles. You'd *have* to use the locale_t-based interfaces (or come up with replacements using a big ugly lock to serialise all access to the process-global locale, or allow only ICU locale support in that build, but those seem like strange lengths to go to just to support a dead version of Solaris). There are still at least a couple of functions that lack XXX_l variants in the standard: mbstowcs() and wcstombs() (though we use the non-standard _l variants if we find them in <xlocale.h>), but that's OK because we use uselocale() and not setlocale(), because uselocale() is required to be thread-local. The use of setlocale() to set up the per-backend/per-database default locale would have to be replaced with uselocale(). In other words, I think wrasse would not be coming with us on this hypothetical quest.
