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

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Idea #1

> For output, which happens with sprintf(ptr, "%.15g%s", ...) in
> execute.c, perhaps we could use our in-tree Ryu routine instead?

> For input, which happens with strtod() in data.c, rats, we don't have
> a parser and I understand that it is not for the faint of heart

Yeah. Getting rid of ecpg's use of uselocale() would certainly be
nice, but I'm not ready to add our own implementation of strtod()
to get there.

> Idea #2

> Perhaps we could use snprintf_l() and strtod_l() where available.
> They're not standard, but they are obvious extensions that NetBSD and
> Windows have, and those are the two systems for which we are doing
> grotty things in that code.

Oooh, shiny. I do not see any man page for strtod_l, but I do see
that it's declared on mamba's host. I wonder how long they've had it?
The man page for snprintf_l appears to be quite ancient, so we could
hope that strtod_l is available on all versions anyone cares about.

> That would amount to extending
> pg_locale.c's philosophy: either you must have uselocale(), or the
> full set of _l() functions (that POSIX failed to standardise, dunno
> what the history is behind that, seems weird).

Yeah. I'd say the _l functions should be preferred over uselocale()
if available, but sadly they're not there on common systems. (It
looks like glibc has strtod_l but not snprintf_l, which is odd.)

regards, tom lane