In article <17560000.1050934110@leeloo.intern.geht.de> you write:
>> I've been thinking this would be a good idea for some time, but for a
>> completely different reason.  At the moment, NetBSD extensions are
>> wrapped in:
>>
>># if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
>>     !defined(_XOPEN_SOURCE)
>But not all of them. Eg. the u_int type needed for RPC is covered by a
>#if !defined(_POSIX_SOURCE) && !defined(_XOPEN_SOURCE)

That's because it's in <sys/types.h>, which no ANSI C program will ever
include, so there's no need to protect ANSI C programs from it.  On the
other hand, the fact that it uses _POSIX_SOURCE rather than _POSIX_C_SOURCE
looks like being a bug, and a demonstration of why having _NETBSD_SOURCE
would be helpful.

>> I think it would make life less complicated if we had _NETBSD_SOURCE
>> (say), which was defined by <sys/featuretest.h> if the application
>> hadn't requested a more restrictive standard.  Of course, an
>> application could define _NETBSD_SOURCE for itself if it wanted to
>> ensure that it got our extensions.  This would be much like GNU libc
>> works, but less complicated because we don't try to conform to so many
>> standards.
>FreeBSD 5 has something like set, too. They're setting a __BSD_VISIBLE in 
>sys/cdefs.h. But, it isn't supposed to be changed from outside. If you set 
>POSIX* you're lost..

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.

>> For added points, we could arrange that the value of _NETBSD_SOURCE be
>> significant, so that you could get NetBSD's extensions as of some date
>> by setting _NETBSD_SOURCE to that date (or __NetBSD_Version__, or
>> whatever).
>Hmm.. IMHO it's to complicated. I like the simple "extensions on/off" way 
>Solaris and Glibc handle it.

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
more", this problem is avoided.  I suspect that most application authors
would find this all too confusing, though.

>> In Python's case, the fact that it's including an RPC header file
>> indicates that it's asking for an extension to POSIX, so after that we
>> can legitimately trample the namespace all we want.  Unfortunately,
>> this would mean re-including all the already-included header files
>Hmm.. I'm not sure if I understand your point correctly.

You don't.  My point was that Python shouldn't _need_ to set _NETBSD_SOURCE,
because the fact that it's including <rpc/types.h> indicates that it wants
an extension to POSIX, since that header doesn't exist in POSIX. 
Unfortunately, actually implementing this is probably more trouble than it's
worth.

> But, if I Do 
>something like this:
>
>#define _POSIX_C_SOURCE 200112L
>#define _XOPEN_SOURCE 600
>#define _XOPEN_SOURCE_EXTENDED 1
>#define _NETBSD_SOURCE 1
>
>#include <sys/types.h>
>#include <rpc/types>
>#include <rpc/clnt.h>
>...
>
>It should "just work".

Having to define _NETBSD_SOURCE is hardly "just working".

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

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