Re: check_strxfrm_bug()

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: check_strxfrm_bug()
Date: 2023-06-11 22:15:15
Message-ID: CA+hUKG+r0cuC26mf2cWABhtEkSR6wxAOskkgmNH2UU2UGpReFQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-06-12 00:04:01 Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH
Previous Message Joel Jacobson 2023-06-11 20:15:37 Re: Do we want a hashset type?