Re: Remaining dependency on setlocale()

On Sat, 2024-08-10 at 09:42 +1200, Thomas Munro wrote:
> 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

The objection seems to be very general: that uselocale() modifies the
thread state and affects calls a long distance from uselocale(). I
don't disagree with the general sentiment. But in effect, that just
prevents people migrating away from setlocale(), to which the same
argument applies, and is additionally thread-unsafe.

The only alternative is to essentially ban the use of non-_l variants,
which is fine I suppose, but causes a fair amount of code churn.

> 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...

If we're going to do that, why not just have ascii-only variants of our
own? pg_ascii_isspace(...) is at least as readable as isspace_l(...,
LC_C_LOCALE).

Regards,
Jeff Davis