From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12550 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lib.gnulib.bugs Subject: Re: localename: add support for musl libc Date: Sun, 25 Feb 2018 13:19:04 -0500 Message-ID: <20180225181904.GN1436@brightrain.aerifal.cx> References: <6726776.syxiYx1ubZ@omega> <20180225075444.GB1188@tomato> <7452235.CQINynMRMO@omega> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1519582651 8176 195.159.176.226 (25 Feb 2018 18:17:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Feb 2018 18:17:31 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Assaf Gordon , bug-gnulib@gnu.org, musl@lists.openwall.com To: Bruno Haible Original-X-From: musl-return-12566-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 25 19:17:27 2018 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.84_2) (envelope-from ) id 1eq0rW-0001kf-7k for gllmg-musl@m.gmane.org; Sun, 25 Feb 2018 19:17:26 +0100 Original-Received: (qmail 16000 invoked by uid 550); 25 Feb 2018 18:19: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 15946 invoked from network); 25 Feb 2018 18:19:21 -0000 Content-Disposition: inline In-Reply-To: <7452235.CQINynMRMO@omega> Xref: news.gmane.org gmane.linux.lib.musl.general:12550 gmane.comp.lib.gnulib.bugs:38476 Archived-At: On Sun, Feb 25, 2018 at 11:17:08AM +0100, Bruno Haible wrote: > Hi Assaf, > > > > +# elif defined __linux__ && HAVE_LANGINFO_H && defined NL_LOCALE_NAME > > > + /* musl libc */ > > > > A tiny comment about the comment :) > > > > You wrote "musl libc", but what the "elif defined ..." is something like > > "linux but not glibc, with langinfo.h" - which could (in theory) be > > something other than musl-libc. > > Yes, that's it. The refusal of the musl people to define a symbol such > as __MUSL__ [1] makes it hard to write future-proof code. If someone else The existence of it would not help futureproof and would promote writing of non-futureproof code by hardcoding specific assumptions about a specific version of musl rather than configure-time or preprocessor-time detection of features. > creates a platform that shares the same superficial characteristics > (runs on Linux, has and NL_LOCALE_NAME) but behaves > differently, we will accidentally run into the code intended for musl > on that platform. Whereas the fallback code (return "" in this case) > would be safer: it would make the unit test fail, but it would not > lead to a compilation error or to a code dump. > > And if that platform does not have an identifiying macro either, we > really got a problem how to distinguish the two. The comment /* musl */ above is wrong and should not have been added. Really use of NL_LOCALE_NAME should always be preferred if it's available, since it's a clean public interface for the functionality desired rather than a hack poking at implementation internals. But if you really like poking at internals for other implementations, it also works to leave it as the fallback case after the hardcoded list of assumptions about particular known platforms. It should just be called something more reasonable like /* otherwise, use public NL_LOCALE_NAME interface if the system has it */ instead of /* musl */. Rich