mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Re: Best bikeshed ever (feature test macros)
Date: Wed, 29 Aug 2012 10:43:47 -0400	[thread overview]
Message-ID: <20120829144347.GU27715@brightrain.aerifal.cx> (raw)
In-Reply-To: <503E20B9.7060705@purdue.edu>

On Wed, Aug 29, 2012 at 10:01:29AM -0400, Gregor Richards wrote:
> 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.

At the very least, the stuff that was in _XOPEN_SOURCE=600 but removed
in 700 is probably wanted (gethostbyname, usleep, etc.).

There are also a small number of legacy interfaces that are really
only relevant to core programs: setgroups, chroot, sethostname, ...;
I'm not sure if it's really important to expose these by default if
the goal is just to avoid having to patch or add CFLAGS to _every_
program. Having to fix-up a few core programs is not such a big deal
since it's effectively O(1) effort rather than O(n).

Perhaps a bigger issue is what uglyware like GCC does when *_unlocked,
*64, etc. exist in libc but don't get exposed in the headers by
default. My leaning would be strongly against exposing this junk by
default, but I would also be interested in whether any changes we'd
make would improve the situation building GCC or make it even worse...

> _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 think the practical difference is insufficient to matter, and
certainly insufficient to justify adding yet another feature test
macro. Since there's really little (i.e. nothing) you can rely on when
omitting all feature test macros (see the difference in how the BSDs
treat it vs what glibc does, etc.), I'm also unconvinced of the value
of trying to keep the set of functionality fixed. My practical goals
for it would be:

1. Don't bring in symbols that are likely to break real-world
software. Note that this only affects software not using feature test
macros.

2. Don't pull in ridiculous amounts of header creep where one header
includes another that includes another and you end up having macros
like major() and minor() or arch-specific CPU register names like
"eax" getting exposed in every program that includes stdlib.h...

3. Make as much software as possible "just work".

> 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.

If we did ever add _SVID_SOURCE, I see no reason to add STREAMS or any
other deprecated/harmful functionality. The macro would just enable
functionality that we already support that's not included in POSIX/XSI
but that was present in SVID.

Rich


  reply	other threads:[~2012-08-29 14:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-24 21:41 Rich Felker
2012-08-24 22:24 ` Gregor Richards
2012-08-24 23:59 ` Szabolcs Nagy
2012-08-25  7:35 ` orc
2012-08-25 12:32   ` Rich Felker
2012-08-25 15:29     ` orc
2012-08-25  9:11 ` Luca Barbato
2012-08-27 18:08 ` Isaac Dunham
2012-08-29  5:34 ` philomath
2012-08-29 13:49   ` Rich Felker
2012-08-29 14:01     ` Gregor Richards
2012-08-29 14:43       ` Rich Felker [this message]
2012-08-29 15:08         ` Bobby Bingham
2012-08-29 15:23           ` Rich Felker
2012-08-29 17:17             ` Gregor Richards
2012-08-29 17:59       ` Isaac Dunham
2012-08-29 18:08         ` Rich Felker
2012-09-02  8:48 ` Arvid E. Picciani
2012-09-02 15:19   ` Rich Felker
2012-09-02 15:27     ` Arvid E. Picciani
2012-09-02 15:44       ` Rich Felker
2012-09-02 17:00 ` nwmcsween
2012-09-02 17:06   ` Gregor Richards
2012-09-02 17:13     ` Rich Felker
2012-09-02 17:18       ` Gregor Richards
2012-09-02 17:10   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120829144347.GU27715@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).