From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9821 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible bug in setlocale upon invalid LC_ALL value Date: Fri, 1 Apr 2016 20:58:58 -0400 Message-ID: <20160402005858.GA21636@brightrain.aerifal.cx> References: <4C4AEBC7-4344-4867-B8F6-F1A691F123E0@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1459558767 23328 80.91.229.3 (2 Apr 2016 00:59:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Apr 2016 00:59:27 +0000 (UTC) Cc: musl@lists.openwall.com To: Assaf Gordon Original-X-From: musl-return-9834-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 02 02:59:26 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1am9uQ-000673-4n for gllmg-musl@m.gmane.org; Sat, 02 Apr 2016 02:59:26 +0200 Original-Received: (qmail 22075 invoked by uid 550); 2 Apr 2016 00:59:23 -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 22054 invoked from network); 2 Apr 2016 00:59:22 -0000 Content-Disposition: inline In-Reply-To: <4C4AEBC7-4344-4867-B8F6-F1A691F123E0@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9821 Archived-At: On Fri, Apr 01, 2016 at 08:47:01PM -0400, Assaf Gordon wrote: > Hello musl developers, > > I'm testing compilation of GNU coreutils on Alpine Linux 3.3.3 (linux kernel 4.1.20, musl-1.1.12-r3). > > I think I've encountered a problem in musl, where using setlocale with invalid locale name returns the invalid locale instead of a known locale. > example: > > $ LC_ALL=missing ./myprogram > > If myprogram calls setlocale(LC_ALL,""), > then musl sets the internal locale despite being invalid value. > later, checking the locale for a specific category (e.g. LC_COLLATE) will return 'missing' instead of 'C' . > > > The relevant POSIX clause is this: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html > "[...] If the value of any of these environment variable searches yields a locale that > is not supported (and non-null), setlocale() shall return a null pointer and the global > locale shall not be changed." > > Below is a short C program demonstrating the issue, with example output from various OSes. This is intentional. All locale names are valid under musl, and those which don't have any particular definition are just aliases for C.UTF-8. The alternative would be that UTF-8 support breaks whenever LC_* vars are set but locales are not installed/configured, which would pretty much _always_ be the case when running a static-linked standalone binary on a non-musl-based system (where LC_* are probably set to something the main host libc recognizes). One possibility if this behavior is problematic would be to only consider names without their own definitions as aliases for C.UTF-8 when MUSL_LOCPATH is not set. However I think we'd need to see a strong motivation for doing that, since it seems like it would be worse behavior in some ways, especially when using LC_MESSAGES set to a language for which you don't have a locale installed. Rich