Subject: -Dunix predefine
To: None <tech-userlevel@NetBSD.ORG>
From: Ross Harvey <ross@teraflop.com>
List: tech-userlevel
Date: 06/20/1998 17:33:51
Some of the NetBSD ports predefine unix=1 and some, at least alpha, do not.

I've been told that "the project" decided two years ago to drop this
predefine, but then did not do it. Although it would be acceptable to me
to have it or not have it, at a minimum our various ports must do the same
thing. Anyway two years is a long time, and I think the older discussion
has exceeded its TTL, especially since no action was taken.

So, if I end up adding this to port-alpha, please no one panic...we can
remove it from all the ports together, but until (and if) this is done we
need to be the same.

It does seem to me that we should define this symbol. I have checked Solaris,
IRIX, SunOS, FreeBSD, Digital Unix, an older IRIX, an older DUh, VAX Ultrix,
NetBSD/i386, and Cray Unicos.

Every last one of them defines it by default.

I tried to get a couple of them to undefine it by restricting the environment
using cc(1) options and feature test macros like _POSIX_C_SOURCE. DUh would
drop the definition and enable __STDC__ under the non-default -std1, but
_POSIX_C_SOURCE had no effect and Solaris defined both __STDC__ and unix
by default. I would imagine, however, that a more serious effort would find
that at least some of these systems drop the predefine in one of the (rarely
used) strictly conforming environments. Probably some would kill it inside
an ANSI-symbols-only environment, but that environment is so useless no one
ever uses it.

Please don't advance an (otherwise reasonable) knee-jerk "namespace pollution"
argument here. This symbol is effectively reserved in the namespace. No
portable program can use it. In fact, if we do _not_ define it we are
allowing non-portable programs that use "unix" to compile successfully
on NetBSD when they can't work anywhere else. It would have the same effect
as prototyping something like open() in <stdio.h> so the (posix-required)
include of <fcntl.h> didn't need to be done...an obstacle to portability.

And obviously we are preventing de-facto standard portable programs from
compiling on at least some of the NetBSD platforms.

Also, be careful about advancing a "standards" argument. I'm _making_ a
standards argument and a portability argument. Some standards are unwritten
but they still exist and may be even more important than the formalized
ones.  Until a few years ago, fopen() was in a standard but open() was not.
We didn't stop defining open().  Then, open() appeared in a standard but
sockets did not.  A global predefine is different, I know, but the point
is that not all important interface elements are written down at any given
point in time.

The symbol is quietly defined by tacit agreement among all unix systems
except a couple of NetBSD platforms. I doubt if the rest of the world is
waiting breathlessly for us to undefine it, and I don't really think that
Sun, say, will be fedexing emergency patches out the day after we kill the
symbol (if we do) on NetBSD/i386. :-)

--Ross