From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1808 Path: news.gmane.org!not-for-mail From: nwmcsween@gmail.com Newsgroups: gmane.linux.lib.musl.general Subject: Re: Best bikeshed ever (feature test macros) Date: Sun, 2 Sep 2012 10:00:27 -0700 Message-ID: References: <20120824214138.GA17792@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1346605248 32337 80.91.229.3 (2 Sep 2012 17:00:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Sep 2012 17:00:48 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-1809-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 02 19:00:49 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T8DXS-0002h3-Dl for gllmg-musl@plane.gmane.org; Sun, 02 Sep 2012 19:00:46 +0200 Original-Received: (qmail 13412 invoked by uid 550); 2 Sep 2012 17:00:43 -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 13404 invoked from network); 2 Sep 2012 17:00:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=X3JVmtE1uYiUqKnMGp++L7KrqtM/WK9FXXIEgj6mor0=; b=s9iUr+Nz3sxps4QWBPMlAW7XxvnqcD2UHWorroo8yKlGRcZ1fNlpNnGGgoA6Mkxyr3 MP06cQ3ztM9aV1MST6KAYlp66DiPIiIdBWiWRFtQmEy6hzJK9C+pojkRCJ10LWctGBNB 7pHZv256E4W8GpiSzKEaeMtBEaS7ncYQd/fECkAIG2Q4fHkvGcx4wMi7o4SG3SaLoyOL L5BAtw57vJEt5ZA8Q5+Jv4zLBrpuOIJl6vgN05Ypr+iPCS/K2Ed68DWmdWm6sQsBfaq9 IDOH51Vjjoq3SsQlkZ80si3fM6sWOR2XbBrZLJoIRzyXduO/iUnPPW9J6ftVcmFRYasC K2ag== X-Mailer: iPhone Mail (9A405) In-Reply-To: <20120824214138.GA17792@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1808 Archived-At: On Aug 24, 2012, at 2:41 PM, Rich Felker wrote: > Hi all, >=20 > Feature test macros (the fun -D_POSIX_C_SOURCE=3D200809L, -D_GNU_SOURCE, > etc. things everybody gets wrong) have been one of the more > controversial aspects of musl, particularly the fact that musl > presents by default a straight ISO C conforming environment with no > POSIX, traditional Unix, etc. stuff offending the pristine C > namespace, and requires the use of one or more feature test macros to > get basically _ANY_ typical unixy software to build. >=20 > There's been some (mostly dead-end) discussion over the past few weeks > from folks who are unhappy with this situation or want it to change; I > suspect there are also some purists who want every application out > there to change and make explicit what features it depends on. >=20 > In this thread I'd like to gauge opinions on the matter. In other > words, this is the ultimate bikeshed thread. >=20 > To give it some direction, I'd like to start off with some pros and > cons of the different options... >=20 >=20 > 1. Leaving everything as it is. >=20 > PROS: Obtaining conforming standard C environment is easy. Detecting > (for the purpose of flaming or fixing) programs failing to use feature > test macros correctly is also easy. >=20 > CONS: Basically every program requires a feature test macro to be > added to CFLAGS in order to compile it. Using -D_GNU_SOURCE works 99% > of the time, but the other 1% of the time it will _break_ programs > that are already correctly using -D_XOPEN_SOURCE=3D700 or similar by > introducing nonstandard functions that pollute the namespace and > conflict with the application. Thus it becomes really hard to have a > universal working build procedure. It's also very hard to work around > broken build systems (like GCC's bootstrapping) that refuse to honor > your custom CFLAGS. >=20 >=20 > 2. Making the kitchen sink (_GNU_SOURCE) available by default. >=20 > PROS: Works with most software and won't break software that's already > correctly using feature test macros. >=20 > CONS: The preprocessor logic in the headers becomes MUCH uglier. And > purists may object to this on moral grounds. >=20 >=20 > 3. Making only some limited subset (e.g. POSIX base) available by > default. >=20 > PROS: Easy to do, e.g. by adding "|| !defined(__STRICT_ANSI__)" to all > POSIX functionality #ifs. Cannot break any correct code in the default > configuration except pure ISO C code that's non-POSIX, and even then, > -std=3Dc99 fixes it. Might cause applications to be built with less GNU > interface dependencies. >=20 > CONS: Probably fails to get a significant portion of apps working. >=20 >=20 > Much like the last thread I created to assess opinion (the license > one), this is all fairly open-ended and not necessarily going to lead > to any short- or long-term change in direction, but then again it > could... Replies don't have to be of the form 1/2/3; alternative ideas > are welcome, as are replies that just address which goals/criteria are > most important to you. >=20 > Rich Leave it as is, this actually helps find bugs in software. A real world exam= ple is accidentally utilizing gnu extensions in mruby (see github mruby bug= page for more info).=