From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14647 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 07:44:37 -0400 Message-ID: <20190911114437.GS9017@brightrain.aerifal.cx> References: <20190909175452.GO9017@brightrain.aerifal.cx> <20190910163143.GI22009@port70.net> <20190910184312.GJ22009@port70.net> <539924f1-6cdb-0652-e9bf-4c5e6922823d@adelielinux.org> <20190911100159.GK22009@port70.net> <20190911120722.6ed0b3fb@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="208355"; 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-14663-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 11 13:44:52 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 1i813M-000s6N-Lu for gllmg-musl@m.gmane.org; Wed, 11 Sep 2019 13:44:52 +0200 Original-Received: (qmail 11805 invoked by uid 550); 11 Sep 2019 11:44:50 -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 11787 invoked from network); 11 Sep 2019 11:44:49 -0000 Content-Disposition: inline In-Reply-To: <20190911120722.6ed0b3fb@inria.fr> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14647 Archived-At: 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 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