[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Mar 2012 12:05:42 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 0/4] Fix function definitions.
On Fri, 9 Mar 2012 11:38:53 -0500
Rich Felker <dalias@...ifal.cx> wrote:
> On Fri, Mar 09, 2012 at 09:11:05AM -0600, Rob Landley wrote:
> > Why are you doing feature test macros at _all_ in a 2012 Linux libc? If
> > you don't #define any of them (which most code doesn't), you get (from
> > /usr/lib/features.h):
>
> features.h is part of glibc, and not a part I like, for several
> reasons:
>
> 1. Each additional nested header increases base compile time
> significantly, and makes a big difference for small translation units
> that only includes one header themselves, due to extra path search,
> open, read, parse, close, etc.
>
> 2. The way glibc does features.h, with _xxx_SOURCE macros as the input
> and __USE_xxx macros as the output, obfuscates in the actual headers
> which macros are necessary or sufficient to get the desired interface
> declared.
>
> 3. Others I'm forgetting at the moment.. :-)
>
> Relying on that is not portable, and musl does not do it. On
> Linux/glibc you get the kitchen sink when you define nothing. On most
> other unices, you get an intentionally-broken legacy environment
> that's not conformant to modern standards.
>
> All projects should explicitly define the feature test macros they
> want. This also assists you in profiling the portability of your code
> (switching out _GNU_SOURCE and you see exactly what extensions you're
> using). Thankfully for ones that fail to do this, you can just add the
> appropriate -D's to CPPFLAGS.
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.
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.
> Anyway, the reason I've not focused on adding _BSD_SOURCE is mainly
> lack of necessity. I don't think I've encountered a single package
> that was defining _BSD_SOURCE and failed to build because of things it
> expected to get from _BSD_SOURCE. If there are major packages that
> could be made easier to build by adding it, I'd be a lot more
> interested in doing so.
>
> > I don't care about granularity, I just want my code to work. But I
> > refuse to #define _ALL_HAIL_RICHARD_STALLMAN as a condition of using
> > standard Linux functions.
> >
> > I will not say _GNU_SOURCE when implementing a project that has nothing
> > whatsoever to do with the FSF's GNU project, and acts to replace large
> > chunks of its' userspace.
..
> > >> I think there's a good (nontrivial) discussion to be had about whether
> > >> it's worthwhile to have the _BSD_SOURCE and _SVID_SOURCE feature test
> > >> macros supported in musl.
> >
> > Given that the "nothing is #defined" behavior gives you most of this
> > anyway on both glibc and uClibc, why musl is bothering with it at _all_
> > is kinda inexplicable to me.
>
> Because unlike uClibc, musl does not just copy all the mess from
> glibc.
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.
> > ... And it means that Musl can't build code that not just
> > glibc and uClibc can build out of the box, but BSD can too. (chroot()
> > was _not_ invented by the gnu/dammit project.)
>
> 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?)
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.
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
--
Isaac Dunham <idunham@...abit.com>
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.
