Subject: Re: Solaris like __EXTENSIONS__ ?
To: Marc Recht <firstname.lastname@example.org>
From: Ben Harris <email@example.com>
Date: 04/21/2003 16:14:04
On Mon, 21 Apr 2003, Marc Recht wrote:
> >> FreeBSD 5 has something like set, too. They're setting a __BSD_VISIBLE
> > That seems a little silly, since that conflicts with the way that other
> > feature-test macros work. You're explicitly allowed to define both
> > _POSIX_C_SOURCE and _XOPEN_SOURCE, for instance, and that's equivalent to
> > defining _XOPEN_SOURCE on its own.
> You're allowed to do that on FreeBSD, but then __BSD_VISIBLE isn't set.
> __BSD_VISIBLE itself is used like __EXTENSIONS__ on Solaris, to override
> the "if POSIX" stuff. (But, unlike __EXTENSIONS__ it isn't supposed to be
> set by the developer.)
Obviously you're allowed to define _POSIX_C_SOURCE and _XOPEN_SOURCE. My
point was that we should make _NETBSD_SOURCE follow the same model, so
you're similarly allowed to define _NETBSD_SOURCE and _XOPEN_SOURCE.
Making the rules different for different macros would be a recipe for
confusion, and you suggest that this is effectively what FreeBSD have
> > We could arrange that setting _NETBSD_SOURCE to 1 (or empty) caused it to
> > default to the latest version, but yes, that might be a bit complex. The
> > problem is that without it, there's no way an application setting
> > _NETBSD_SOURCE can be sure we won't arbitrarily trample some bit of their
> > namespace in a future version. If they can say "I'm happy for you to
> > trample the parts of my namespace that you used in version 1.6, but no
> I think of _NETBSD_SOURCE of something like "give me all the system has to
> offer" and that changes a bit from OS version to OS version.
Yeah, that's probably be best approach. It does mean that you can't be
certain of an application that uses _NETBSD_SOURCE continuing to compile
correctly on new versions of the system, though.
> > more", this problem is avoided. I suspect that most application authors
> > would find this all too confusing, though.
> I don't think so. Solaris and Linux handle it that way, so that most
> developers should know that concept.
Oops. Antecedent confusion. My "this" was "versioned _NETBSD_SOURCE".
> >> For the Python RPC case this would be enough:
> >># if defined(_NETBSD_SOURCE) || (!defined(_POSIX_SOURCE) &&
> >> !defined(_XOPEN_SOURCE))
> > Actually, I'd like that to be:
> ># if defined(_NETBSD_SOURCE)
> > with _NETBSD_SOURCE being defined by <sys/featuretest.h> if none of the
> > other macros is defined.
> But won't that break (stricly) POSIX conforming applications which set
> POSIX* ? But, don't (and don't want to) know about OS extensions?
A strict POSIX application will define _POSIX_C_SOURCE, and won't define
_NETBSD_SOURCE (since that's in the implementation's namespace). Because
_POSIX_C_SOURCE is defined, <sys/featuretest.h> wouldn't define
For avoidance of doubt, here's what I'd propose putting into
<sys/featuretest.h>, after the current check for _POSIX_SOURCE:
#if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
!defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
#define _NETBSD_SOURCE 1
Ben Harris <firstname.lastname@example.org>
Portmaster, NetBSD/acorn26 <URL:http://www.netbsd.org/Ports/acorn26/>