From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1784 Path: news.gmane.org!not-for-mail From: Gregor Richards Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Best bikeshed ever (feature test macros) Date: Wed, 29 Aug 2012 10:01:29 -0400 Message-ID: <503E20B9.7060705@purdue.edu> References: <20120824214138.GA17792@brightrain.aerifal.cx> <20120829073442.66c72367@gmail.com> <20120829134939.GS27715@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 1346248914 18737 80.91.229.3 (29 Aug 2012 14:01:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2012 14:01:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1785-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 29 16:01:55 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 1T6iqB-0006Yt-Fo for gllmg-musl@plane.gmane.org; Wed, 29 Aug 2012 16:01:55 +0200 Original-Received: (qmail 30503 invoked by uid 550); 29 Aug 2012 14:01:44 -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 30495 invoked from network); 29 Aug 2012 14:01:43 -0000 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <20120829134939.GS27715@brightrain.aerifal.cx> X-PMX-Version: 5.5.9.388399 X-PerlMx-Virus-Scanned: Yes Xref: news.gmane.org gmane.linux.lib.musl.general:1784 Archived-At: On 08/29/2012 09:49 AM, Rich Felker wrote: > On Wed, Aug 29, 2012 at 07:34:42AM +0200, philomath wrote: >> On Fri, 24 Aug 2012 17:41:38 -0400 >> Rich Felker wrote: >> >> >>> 1. Leaving everything as it is. >>> 2. Making the kitchen sink (_GNU_SOURCE) available by default. >>> 3. Making only some limited subset (e.g. POSIX base) available by >>> default. >> The bikeshed should definitely not be colored black. >> >> I'd lean towards 3, 1 is fine too. but please not 2, musl's >> correctness is one of it's unique features... >> >> Thanks. > Thanks for the input. What correctness aspect is important to you? I > conceptually like the minimal-by-default namespace, but ISO C does not > specify how to invoke the compiler, so even implementations that > require you to use obscure options to get a clean plain-C namespace > are "correct". In practice, any of the options 1-3 would give the > clean namespace as long as -std=c* is used with no feature test > macros. > > With that said, I do tend to agree that option 2 is ugly, mainly since > it exposes not just useful modern extensions but all kinds of ugly > legacy things, like sys/sysmacros.h junk getting pulled in from > standard headers... So far the most reasonable proposals I've seen are > along the lines of "XSI plus some extensions" where the latter would > correspond to _BSD_SOURCE or some analogue of _SVID_SOURCE (which is > not supported by musl at this time). > > Rich I'll repeat some followups I had on IRC here: _XOPEN_SOURCE=700 has the advantage that it does include lots of things, and is a standard, so it's not an arbitrary moving target. It's probably not sufficient, but I'm not wholly convinced of that. _BSD_SOURCE (which on musl apparently implies _XOPEN_SOURCE, which makes sense since it's not like they're not trying) is better, the only reason I don't like it is that it's not a standard, so there's no clear demarcation of what it could imply, and arbitrary new things from the BSDs could be added at any point. In practice this may be irrelevant since all the BSDs are more-or-less stagnant, but in principle it's iffy. I would like something like _44BSD_SOURCE only so that it's not a moving target, but I can see how most people would probably find that offensive. I thought _SVID_SOURCE would be a reasonable intermediary because it's also a standard, but an olde and sort of nutty one. Upon a quick review of glibc's headers, there's actually very little that _SVID_SOURCE gives you but _XOPEN_SOURCE=700 doesn't, so it's unlikely to be very helpful. Besides, the STREAMS API is required in SVID, and obsolete in SUS. With valediction, - Gregor Richards