From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6761 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: the case for __MUSL__ Date: Mon, 29 Dec 2014 16:55:49 -0500 Message-ID: <20141229215549.GO4574@brightrain.aerifal.cx> References: <20141229173713.GM4574@brightrain.aerifal.cx> <0E7DD0A2-5CD3-4695-AE48-3C95E6FB195B@cognitive-electronics.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 1419890176 19334 80.91.229.3 (29 Dec 2014 21:56:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Dec 2014 21:56:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6774-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 29 22:56:10 2014 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 1Y5iIH-0000mT-9j for gllmg-musl@m.gmane.org; Mon, 29 Dec 2014 22:56:05 +0100 Original-Received: (qmail 30285 invoked by uid 550); 29 Dec 2014 21:56:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30269 invoked from network); 29 Dec 2014 21:56:03 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6761 Archived-At: On Mon, Dec 29, 2014 at 11:59:39AM -0600, Josiah Worcester wrote: > On Dec 29, 2014 11:51 AM, "Richard Gorton" < > rcgorton@cognitive-electronics.com> wrote: > > > > > > That is a single example of some of the code in a library which is NOT > musl. > > There are other places in the example library which know about __APPLE__ > or __GLIBC__ or __sun__ > > > > My thought is to use __MUSL__ in those libraries as appropriate in place > of ____ as the backing libc is musl. > > > > And said use of __MUSL__ is what I am interested in feedback about. > > > > The intent of not providing it is to force applications to use a portable > interface rather then being libc specific. So, everyone's leaping to try > and find ways to not need that. > Sorry for the mismatched expectations. Exactly. The intent is that musl should be supported by the #else case with the portable code in it, or (even better) that all cases but the #else should be removed as unnecessary so that the same code is used everywhere. In cases where musl is providing some non-standard interface from glibc or BSD that you actually want to use, the right way to use it is to test for its availability at compiletime with either some sort of configure process (autoconf or similar) or via feature-specific macros (like the ones POSIX defines for optional POSIX functionality in unistd.h, although nothing like that exists yet for non-standard extensions). Using a macro like __MUSL__ or __GLIBC__ to enable use of such interfaces is not reasonable since it requires hard-coding assumptions about which extensions are available in particular versions rather than actually checking for the availability of the interface you want. Rich