Subject: Re: Solaris like __EXTENSIONS__ ?
To: None <email@example.com>
From: Ben Harris <firstname.lastname@example.org>
Date: 04/21/2003 15:25:11
In article <email@example.com> 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) && \
>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
>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
>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
> 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
>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) &&
Actually, I'd like that to be:
with _NETBSD_SOURCE being defined by <sys/featuretest.h> if none of the
other macros is defined.
Ben Harris <firstname.lastname@example.org>
Portmaster, NetBSD/acorn26 <URL:http://www.netbsd.org/Ports/acorn26/>