From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/665 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 0/4] Fix function definitions. Date: Fri, 16 Mar 2012 18:48:55 -0400 Message-ID: <20120316224855.GA22075@brightrain.aerifal.cx> References: <1331280854-9080-1-git-send-email-gf@unixsol.org> <4F59BD70.9020105@unixsol.org> <20120309083358.GA184@brightrain.aerifal.cx> <4F59CA50.5060407@unixsol.org> <4F5A1D89.9090304@landley.net> <20120309163853.GF184@brightrain.aerifal.cx> <20120316120542.82a478fe.idunham@lavabit.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: dough.gmane.org 1331938126 23760 80.91.229.3 (16 Mar 2012 22:48:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Mar 2012 22:48:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-666-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 16 23:48:45 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 1S8fwy-0002b2-M0 for gllmg-musl@plane.gmane.org; Fri, 16 Mar 2012 23:48:44 +0100 Original-Received: (qmail 12212 invoked by uid 550); 16 Mar 2012 22:48: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 12204 invoked from network); 16 Mar 2012 22:48:43 -0000 Content-Disposition: inline In-Reply-To: <20120316120542.82a478fe.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:665 Archived-At: On Fri, Mar 16, 2012 at 12:05:42PM -0700, Isaac Dunham wrote: > Strikes me that just because you don't #include in > every other header doesn't require making it a NOP. > I don't think features.h is in the reserved namespace. It's not. > So why not have #define _KITCHEN_SINK_SOURCE in there, and let > whoever wants that go > #include > ? > Just because it converts macros internally, or GNU includes it, > doesn't mean you have to include it or handle macros same way to > ship it in a semi-compatible state. > IF a programmer #include's features.h themselves, they asked for the > kitchen sink; ignoring that is wrong. Actually, if a program is including features.h, the author is either (1) unclear what they were trying to accomplish, or (2) trying to force the feature test macros to be processed early, before other files are included or defines take effect. With glibc, all feature test macros take effect the first time features.h is included, so including it early could suppress consideration of feature test macros getting defined (or undefined) later (e.g. within a library header file). Of course such usage is extremely non-portable; the only valid way to use feature test macros is defining them before any system header is included, and never undefining or redefining them later. Perhaps including features.h without defining any feature test macros at all could be construed as "asking for the kitchen sink", but I find that interpretation a bit doubtful since the behavior (on glibc) is unchanged from what they would have gotten without including it. > I'd like to see at least _BSD_SOURCE available, provided that > 1. It actually is a BSD-ish API, with similar scope to NetBSD or > glibc's _BSD_SOURCE > 2. It isn't autodefined when using standard headers. Could you give a summary of what the differences in _BSD_SOURCE and _GNU_SOURCE are? My impression (possibly wrong) is that on glibc it's pretty close to _GNU_SOURCE but without the nasty intentional GNU incompatibilities (like GNU basename) and with some/most of the GNU or Linux-specific extensions missing. I'm quite willing to add proper _BSD_SOURCE support if you (or someone else) is willing to put in the effort to figuring out what it should include. > > It's not my intent to imply that any of these features were invented > > by the GNU project. Rather, _GNU_SOURCE is simply the only existing > > feature test macro for "kitchen sink" that exists on Linux systems. > ... > > The ONLY existing macro? > _BSD_SOURCE is an existing macro, and while it isn't the FULL > kitchen sink, it's a lot closer. > (and apparently close enough for toybox?) Indeed, it's not as much, but it may be sufficient for a lot of things that are highly desirable like MAP_ANONYMOUS. > Also, you seem to be arguing that if it's automatically defined, > then it's not standards compliant, and assume that if the standards > say we can't do that, there's no reason to implement it at all. I never meant to imply that. Sorry. > Here's my proposal: > Would it work to implement _BSD_SOURCE and leave features.h lying > around (read: implemented, but NOT included in any system headers) > with this content: > > #warn "features.h is not portable- use -D_BSD_SOURCE" > #if ((!defined _POSIX_C_SOURCE || _XOPEN_SOURCE || _BSD_SOURCE || > _GNU_SOURCE || __STRICT_ANSI__ || _POSIX_SOURCE )) > #define _BSD_SOURCE > #define _POSIX_C_SOURCE 200809L > #endif I don't see how this really helps. If the goal is to give behavior closer to glibc, you'd want it to define _GNU_SOURCE, not _BSD_SOURCE. But this will fix very few programs (only the ones that include features.h explicitly, which probably means they're doing something very wrong...) when the alternate workaround (adding -D_GNU_SOURCE or whatever is needed to $CC or $CPPFLAGS) is easier and less invasive to programs. In any case I'm interested in adding _BSD_SOURCE if you or someone else will help with getting it right. Rich