Re: check_strxfrm_bug()

On Mon, Apr 17, 2023 at 8:00 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Sun, Dec 18, 2022 at 10:27 AM Thomas Munro <thomas.munro@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.