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

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

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
#endif

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>