[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120316224855.GA22075@brightrain.aerifal.cx>
Date: Fri, 16 Mar 2012 18:48:55 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 0/4] Fix function definitions.
On Fri, Mar 16, 2012 at 12:05:42PM -0700, Isaac Dunham wrote:
> Strikes me that just because you don't #include <features.h> 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 <features.h>
> ?
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
