On Tue, 2 Jan 1996 10:06:07 -0800 (PST), Peter Seebach wrote:
> This is a *stupid fuckup* they refuse to fix.

Say what?

We did fix the problem.  The include of <unistd.h> was added to the Pine 3.92
development sources within a few days of our being alerted to the problem,
many months ago.  This was after Pine 3.91 was released, which is why the fix
is not in Pine 3.91 sources.

Pine 3.92 has not been released yet.  There has been no release since this
problem was first reported.  Once a release is out, it's out; we don't change
it.

The NetBSD port was contributed by a Pine user.  We did not write it.

There are no NetBSD systems here.  It is impossible for use to test the NetBSD
code.

There is no NetBSD documentation here.  We have no way of knowing if NetBSD
uses <unistd.h> or not unless some person who uses it tells us.

We don't write "blind ports", but usually we include ports which were
contributed by users.  The alternative to distributing Pine with contributed
ports of unknown quality is not to distribute contributed ports at all.

This kind of problem is usually caused by a compiler that generates variable
width argument stack frames in the name of "efficiency".  Although PC and Mac
compilers do this all the time, most Unix compilers do not.  Such behavior is
disasterous in pre-ANSI compilers without argument prototyping (which is why
it wasn't done).  Pine is probably not the first program that has run afoul of
this on NetBSD.  Fortunately, since Pine does build on PC and Mac, the problem
goes away once you have the right include files.  Nonetheless, I question the
wisdom of this type of behavior in compilers, since old code (including K&R
first edition examples!) is always going to trip up on this.  Does NetBSD have
a compiler switch (and associated libraries!) which coerces arguments up to
the largest data type?

> Despite the fact that they cannot name a system, anywhere, where
> <unistd.h> exists and including it will break things, they don't
> include <unistd.h>.

VAX Ultrix is an example of a system in which you can not include both
<unistd.h> and <sys/file.h>; <sys/file.h> is the correct file, not <unistd.h>.

NeXT is an example of a system which does not have <unistd.h> at all.

Therefore, we can not blindly include <unistd.h> on all ports.  The decision
has to be made on a case-by-case basis, based on several questions:
	1) does <unistd.h> even exist?
	2) if it exists:
	   2a) is it the real <unistd.h> that provides the primary prototyping
	       for most system functions?
	   2b) or, is it just a pseudo-"POSIX compatibility" stub that has
	       conflicts with the real include files?

If we didn't try to be compatible across a wide range of systems -- including
those in which <unistd.h> is a problem -- then we would end up narrowing our
focus to certain systems which have importance to us.  Almost certainly NetBSD
would not be one of these.