From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1809 Path: news.gmane.org!not-for-mail From: Gregor Richards Newsgroups: gmane.linux.lib.musl.general Subject: Re: Best bikeshed ever (feature test macros) Date: Sun, 02 Sep 2012 13:06:25 -0400 Message-ID: <50439211.6050504@purdue.edu> References: <20120824214138.GA17792@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1346605602 2704 80.91.229.3 (2 Sep 2012 17:06:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Sep 2012 17:06:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1810-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 02 19:06:43 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 1T8DdD-0000NW-7h for gllmg-musl@plane.gmane.org; Sun, 02 Sep 2012 19:06:43 +0200 Original-Received: (qmail 15832 invoked by uid 550); 2 Sep 2012 17:06:40 -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 15824 invoked from network); 2 Sep 2012 17:06:40 -0000 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 In-Reply-To: X-PMX-Version: 5.5.9.388399 X-PerlMx-Virus-Scanned: Yes Xref: news.gmane.org gmane.linux.lib.musl.general:1809 Archived-At: On 09/02/2012 01:00 PM, nwmcsween@gmail.com wrote: > On Aug 24, 2012, at 2:41 PM, Rich Felker wrote: > >> Hi all, >> >> Feature test macros (the fun -D_POSIX_C_SOURCE=200809L, -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. >> >> 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. >> >> In this thread I'd like to gauge opinions on the matter. In other >> words, this is the ultimate bikeshed thread. >> >> To give it some direction, I'd like to start off with some pros and >> cons of the different options... >> >> >> 1. Leaving everything as it is. >> >> 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. >> >> 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=700 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. >> >> >> 2. Making the kitchen sink (_GNU_SOURCE) available by default. >> >> PROS: Works with most software and won't break software that's already >> correctly using feature test macros. >> >> CONS: The preprocessor logic in the headers becomes MUCH uglier. And >> purists may object to this on moral grounds. >> >> >> 3. Making only some limited subset (e.g. POSIX base) available by >> default. >> >> 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=c99 fixes it. Might cause applications to be built with less GNU >> interface dependencies. >> >> CONS: Probably fails to get a significant portion of apps working. >> >> >> 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. >> >> Rich > Leave it as is, this actually helps find bugs in software. A real world example is accidentally utilizing gnu extensions in mruby (see github mruby bug page for more info). The same can be accomplished on any modern libc by using -std=c89 or -std=c99. You shouldn't have to port to a new libc to find these problems, nor should said new libc be designed in such a way that the majority of software doesn't work on it without additional complication. Especially when, as I will repeat over and over again, going through the additional complication to supposedly make your code more portable WILL INVARIABLY MAKE YOUR CODE LESS PORTABLE. With valediction, - Gregor Richards