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

On Tue, Nov 21, 2023 at 5:40 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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.