From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12552 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lib.gnulib.bugs Subject: Re: Re: localename: add support for musl libc Date: Sun, 25 Feb 2018 18:40:35 -0500 Message-ID: <20180225234035.GO1436@brightrain.aerifal.cx> References: <6726776.syxiYx1ubZ@omega> <7452235.CQINynMRMO@omega> <20180225181904.GN1436@brightrain.aerifal.cx> <4622267.x626kDHS96@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 1519601934 30719 195.159.176.226 (25 Feb 2018 23:38:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Feb 2018 23:38:54 +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-12568-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 26 00:38:50 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 1eq5sX-0007iH-UL for gllmg-musl@m.gmane.org; Mon, 26 Feb 2018 00:38:50 +0100 Original-Received: (qmail 4018 invoked by uid 550); 25 Feb 2018 23:40:53 -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 3999 invoked from network); 25 Feb 2018 23:40:52 -0000 Content-Disposition: inline In-Reply-To: <4622267.x626kDHS96@omega> Xref: news.gmane.org gmane.linux.lib.musl.general:12552 gmane.comp.lib.gnulib.bugs:38478 Archived-At: On Sun, Feb 25, 2018 at 10:19:06PM +0100, Bruno Haible wrote: > Hi Rich, > > > 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 ... > > In a perfect world, what you say would make sense. > > However, not all libc versions that define _NL_LOCALE_NAME also have > a _NL_LOCALE_NAME that *works* [1]. It's not that I "really like poking > at internals". It's that I want my code to actually work. Which ones does it not work on, and what happens when it doesn't work? If there are libcs that advertise a feature in their headers but don't actually support it, it sounds like they're the ones that need special-casing. (I think it's old glibc, or some mismatched version of glibc headers and .so, in which case it's already special-cased, right?) But probably it's just a clean failure at runtime (like returning a null pointer) where you can try something else if it failed. > > The comment /* musl */ above is wrong and should not have been added. > > How can you judge that a comment in gnulib code is adequate, when you > are not familiar with the way gnulib is developed? > > The comment /* musl */ says two things: > - If a developer makes changes to these piece of code, they should > test in on a system with musl libc. > - If a developer sees that this code is being compiled/executed on > a system without musl libc, they should review the #if chain, to > make sure no mistake was introduced in #ifs. OK. I think it would have been clearer as: /* Known to work and used on musl libc. Also present * but not always working on [glibc?] so we use the * above case... */ If /* musl */ is fine for conveying that to the people who work on your code, that's one thing, but I still think it's misleading to others who come across and read it, because this is not an interface musl invented but rather one we adopted because glibc, and maybe other systems, already invented something that looked clean & reasonable to solve a problem that had no other clean solution. > Now back to my comment that you haven't addressed, regarding lack of > __MUSL__: > > If someone else > 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. I disagree with the characterization of this code as "intended for musl". It's possible that this is someone's intent, but it's not a programming model musl aims to support. Rather I would see it as code "intended for systems that provide the NL_LOCALE_NAME langinfo item to query the name of the active locale". Whether musl is such a system is version-dependent (1.1.17 or later) and easily determined via configure- or preprocessor-time tests. As for failure on other systems, it's testable at configure time that NL_LOCALE_NAME is a macro accepting locale category macros as arguments and producing an integer result, demonstrating that it won't produce a compile error. In that case the worst thing that happens, unless nl_langinfo is buggy, is returning an empty string or some string that's not the locale name. (I know at one point in the past musl erroneously returned null for undefined items, so it might be worth checking for that too; other implementations might also have had that bug at some point.) > And if that platform does not have an identifiying macro either, we > really got a problem how to distinguish the two. I'm not clear what further distinguishing is needed. We've discussed before and are open to designing an approach to advertise extended functionality via macros defined in the standard headers -- something like the _POSIX_* macros unistd.h defines, but for extensions. But not just an "I am musl, go assume whatever was true in the version of musl you looked at" macro. But in order for this to move forward there should really be some interest in collaboration between implementations (I think glibc would be open to it now, maybe one or more BSDs too) and input from application programers (the consumers of the macros) on what would be useful to them. Rich