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