[ From current-users, but tech-userlevel is more appropriate. ]

In article <115700000.1050860603@leeloo.intern.geht.de> you write:
>I've currently some trouble with a 3rd party application (Python 2.3/CVS)
>which sets:
>_POSIX_C_SOURCE 200112L
>_XOPEN_SOURCE 600
>_XOPEN_SOURCE_EXTENDED 1
>by default. But, it still uses eg. rpc, which won't compile, because u_int
>isn't defined in the POSIX case. Solaris solves such issues by letting the
>user define __EXTENSIONS__ to get the extended system interfaces.
>Eg. (Solaris 8 sys/types.h):
>#if defined(__EXTENSIONS__) || \
>        (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE))
>[...]
>
>Linux has _GNU_SOURCE for such cases. I didn't find something like that on
>my 1.6R system.
>IMHO is important to set something like a "POSIX++" environment, because
>it's _a lot_ easier to setup a CFLAGS with  __EXTENSIONS__=1 in the
>environment and run "configure" than changing 3rd party code.

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)

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.

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

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

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