[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190911171545.437a2033@inria.fr>
Date: Wed, 11 Sep 2019 17:15:45 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: printf doesn't respect locale
Hello Rich,
On Wed, 11 Sep 2019 09:47:27 -0400 Rich Felker <dalias@...c.org> wrote:
> > > 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.
> >
> > Interesting.
> >
> > Would this be difficult to implement in musl? (I guess not)
>
> I would think not, but I'd have to look at the details a little more.
>
> One other advantage of this approach is that it has a more graceful
> fallback. If an application needs portable LC_NUMERIC behavior, it can
> check at build time for the presence of the new interface. If present,
> LC_NUMERIC can be set to "" (user's preference) and the new interface
> can be used to get the needed behavior. If absent, the application can
> refrain from setting LC_NUMERIC, only setting the other categories and
> leaving it as "C" (default).
>
> Note that having it be thread-locally stateful is, in my opinion, much
> better than having new variants of the affected functions or new
> formats, since a caller using LC_NUMERIC can set/restore the state to
> safely call library code that's completely unaware of the new
> interfaces.
>
> Of course there may be complications I haven't thought of. One that
> comes to mind right away is what localeconv() should return under such
> conditions.
Ok, yes so this path sounds much more promissing than to concur with
all the different parties to find a free modification character, and
agree on the semantics.
> > Would you be willing to write this up?
>
> What form would it need to be in?
At the end this should be an N-document to submit to WG14, but that is
really at the end. Just one or two pages would be good to get perhaps
some discussion going, first, and also make it clear what it would
imply for and need from musl.
Do you think that a highlevel implementation using _Thread_local or
(tss calls) and setlocale would be doable, such that we could even
provide a reference implementation for all POSIX systems that also
implement some form of thread local variables?
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
