Re: printf doesn't respect locale

[Rich Felker <dalias@libc.org>]

On Wed, Sep 11, 2019 at 12:07:22PM +0200, Jens Gustedt wrote:
> Hello Szabolcs,
> 
> On Wed, 11 Sep 2019 12:01:59 +0200 Szabolcs Nagy <nsz@port70.net> wrote:
> 
> > > We would be *extremely* disappointed if LC_NUMERIC would never be
> > > supported in upstream musl.  We would have to maintain a patch to
> > > add LC_NUMERIC support when the rest of musl's locale support is
> > > developed.  
> > 
> > i consider this a posix/iso c bug.
> 
> I agree
> 
> > there is a need for printf with fixed C.UTF-8 locale in
> > library code that implements a file format, language or
> > protocol that cannot be locale dependent.
> > 
> > in iso c there is no way to get this.
> > 
> > in posix 2008 you have to jump through very bizarre hoops
> > to get it (in a slow and resource wasting way).
> > 
> > so the world is full of printf users that just expect
> > fixed C.UTF-8 locale and hope nobody calls setlocale.
> > 
> > telling ppl that their code is wrong does not help unless
> > you provide an alternative, but introducing new api for
> > this would not be portable.
> 
> I think that WG14 would be happy to hear any suggestions how we could
> get out of this trap, a proposal for C2x would even be better.

The obvious solution is a modifier character to printf/scanf format
strings that applies to numeric conversions and means "always
format/interpret this as if in the C locale". However this is hard to
test for at build time unless there's a macro declaring its
availability, so ideally WG14 would also adopt the sort of
fine-grained feature availability macros some of us have been
proposing for extensions.

An alternative/additional solution, which I actually might like
better, is having a function which sets a thread-local flag to treat
certain locale properties (at least the problematic LC_NUMERIC ones)
as if the current locale were "C". This is weaker than the uselocale
API from POSIX, but doesn't have the problems with the possibility of
failure (likely with no way to make forward progress) like it does,
and more importantly, would avoid *breaking* m17n/i18n functionality
by turning off other unrelated, non-problematic locale features.
Application or library code could then just set/restore this flag
around *printf/*scanf/strto*/etc calls, or could set it and leave it
if they never want to see ',' again.

Rich