Re: On non-Windows, hard depend on uselocale(3)

On Tue, Nov 21, 2023 at 5:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > If we are sure that we'll *never* want locale-aware printf-family
> > functions (ie we *always* want "C" locale), then in the thought
> > experiment above where I suggested we supply replacement _l()
> > functions, we could just skip that for the printf family, but make
> > that above comment actually true.  Perhaps with Ryu, but otherwise by
> > punting to libc _l() or uselocale() save/restore.

Here is a new attempt at this can of portability worms.  This time:

* pg_get_c_locale() is available to anyone who needs a "C" locale_t
* ECPG uses strtod_l(..., pg_get_c_locale()) for parsing
* snprintf.c always uses "C" for floats, so it conforms to its own
documented behaviour, and ECPG doesn't have to do anything special

I'm not trying to offer a working *printf_l() family to the whole tree
because it seems like really we only ever care about "C" for this
purpose.  So snprintf.c internally uses pg_get_c_locale() with
snprintf_l(), _snprintf_l() or uselocale()/snprintf()/uselocale()
depending on platform.

> It is pretty annoying that we've got that shiny Ryu code and can't
> use it here.  From memory, we did look into that and concluded that
> Ryu wasn't amenable to providing "exactly this many digits" as is
> required by most variants of printf's conversion specs.  But maybe
> somebody should go try harder.  (Worst case, you could do rounding
> off by hand on the produced digit string, but that's ugly...)

Yeah it does seem like a promising idea, but I haven't looked into it myself.