From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14657 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf doesn't respect locale Date: Wed, 11 Sep 2019 11:38:53 -0400 Message-ID: <20190911153853.GY9017@brightrain.aerifal.cx> References: <20190910163143.GI22009@port70.net> <20190910184312.GJ22009@port70.net> <539924f1-6cdb-0652-e9bf-4c5e6922823d@adelielinux.org> <20190911100159.GK22009@port70.net> <20190911120722.6ed0b3fb@inria.fr> <20190911114437.GS9017@brightrain.aerifal.cx> <20190911145336.08554c4e@inria.fr> <20190911134727.GU9017@brightrain.aerifal.cx> <20190911171545.437a2033@inria.fr> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="160088"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14673-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 11 17:39:08 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1i84i4-000fYp-NS for gllmg-musl@m.gmane.org; Wed, 11 Sep 2019 17:39:08 +0200 Original-Received: (qmail 24371 invoked by uid 550); 11 Sep 2019 15:39:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24351 invoked from network); 11 Sep 2019 15:39:05 -0000 Content-Disposition: inline In-Reply-To: <20190911171545.437a2033@inria.fr> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14657 Archived-At: On Wed, Sep 11, 2019 at 05:15:45PM +0200, Jens Gustedt wrote: > Hello Rich, > > On Wed, 11 Sep 2019 09:47:27 -0400 Rich Felker 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? It can't be done in terms of setlocale because setlocale is not thread-safe or thread-local. It could be done in terms of POSIX uselocale, but such an implementation would not be fail-safe -- it needs to be able to allocate a locale_t object via duplocale, since the uselocale API works with a locale_t objects that describe the value of *all* locale categories, rather than the categories being individually settable on a per-thread basis (this is a design flaw in the POSIX interfaces, and the historic xlocale ones they were based on, IMO). So such an implementation could be a pseudo-code/demo of the functionality, but I think I'd want the proposed functionality to be always-succeeds to discourage erroneous code that ignores the result (resulting in wrong formatting/parsing, which is unsafe) or aborts the program (eew). Rich