Subject: Re: Solaris like __EXTENSIONS__ ?
To: Ben Harris <bjh21@netbsd.org>
From: Marc Recht <marc@informatik.uni-bremen.de>
List: tech-userlevel
Date: 04/21/2003 16:08:30
> 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)
> which gets even scarier for things is some standards but not others:
>
># if (!defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
> !defined(_XOPEN_SOURCE)) || (_POSIX_C_SOURCE - 0) >= 2 || \
> (_XOPEN_SOURCE - 0) >= 2
>
> 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..
> 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.
> 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. 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". And, normally the std. defines are given as CFLAGS,
so there shouldn't be the problem that rpc* is included after POSIX* has
been defined and before _NETBSD_SOURCE has been defined.
> with new options, which would only work if the multiple-inclusion
> protection took account of feature-test macros, and I don't think we
> want to go there, neat though it would be.
I don't see the probleme here. The environment which will be set up by the
feature test macros (if we really need them..) will be dependend on POSIX*,
XOPEN* and _NETBSD_SOURCE. So, if I'm changing them on compile time I
actually expect things to change..
For the Python RPC case this would be enough:
#if defined(_NETBSD_SOURCE) || (!defined(_POSIX_SOURCE) &&
!defined(_XOPEN_SOURCE))
Regards,
Marc
mundus es fabula