From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14641 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf doesn't respect locale Date: Tue, 10 Sep 2019 20:43:12 +0200 Message-ID: <20190910184312.GJ22009@port70.net> References: <20190909175452.GO9017@brightrain.aerifal.cx> <20190910163143.GI22009@port70.net> 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="61490"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: musl@lists.openwall.com To: Daniel Schoepe Original-X-From: musl-return-14657-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 10 20:43:28 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 1i7l6t-000FuB-SC for gllmg-musl@m.gmane.org; Tue, 10 Sep 2019 20:43:27 +0200 Original-Received: (qmail 17691 invoked by uid 550); 10 Sep 2019 18:43:25 -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 17672 invoked from network); 10 Sep 2019 18:43:24 -0000 Mail-Followup-To: Daniel Schoepe , musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:14641 Archived-At: * Daniel Schoepe [2019-09-10 18:10:20 +0100]: > Basically, someone used printf to produce json output and was unaware > that the radix used by printf was locale-dependent. When this was run > on a system with a non-English locale, it no longer produced valid > JSON as output. ok, i thought using '.' unconditionally caused some problem. i've seen plenty issues with locale dependent radix point when numbers unexpectedly have ',', but the current musl behaviour exactly prevents those types of bugs and i'd prefer to keep it that way. simple scripts parsing some program output will not be tested across different locales. global state dependence is bad in general in systems software which often communicates between machines, not humans, and you cant afford to synchronize that global state or deal with its combinatorics. in particular libraries can't use any api with global state dependence if that state may change asynchronously, thread-local state is a bit better (and since posix2008 locales can be thread-local), but it still has issues e.g. dprintf is implemented to be async-signal-safe, but in a signal handler you can't change the locale setting to get reliable dprintf behaviour and it's inefficient/inconvenient to save/restore tls state around every printf call anyway. i think libc should mainly aim for reliability of systems software and not for friendliness of ui applications. > > Best, > Daniel > > On Tue, Sep 10, 2019 at 5:31 PM Szabolcs Nagy wrote: > > > > * Daniel Schoepe [2019-09-10 17:00:49 +0100]: > > > I'm also not a fan of this behavior, I actually stumbled across this > > > when tracking > > > down a bug the different radix usage caused. > > > > i'm interested in how this can cause a bug in correct software.