Is this wrong?

[Brendan Eich]

In article <1196 at sdrc.UUCP>, crscott at sdrc.UUCP (Scott_Klosterman) writes:
>    The top of the file /usr/include/bsd/sys/ioctl.h contains the
>    following:
> 
> #ifndef __BSD_IOCTL__
> #define __BSD_IOCTL__
> /*
>  * SGI compatibility hack which apes 4.3BSD <sys/ioctl.h>.
>  */
> 
> #include "../../sys/ioctl.h"
> #include <net/soioctl.h>
> #include <sys/ttychars.h>
> 
> 
>     Should the last two lines look like this?
> 
> #include </bsd/net/soioctl.h>
> #include </bsd/sys/ttychars.h>
> 
>     Or am I missing something?  There is no /usr/include/net directory
>     nor a /usr/include/sys/soictl.h

But there is a /usr/include/bsd/net directory.  From intro(3):

     (3B)  The routines in libbsd provide a limited subset of the Berkeley
           4.3BSD UNIX standard C library.  Include files used by these
           routines are in the directory /usr/include/bsd.  To compile and
           link a program that calls any of these routines, use a command of
           the form:

           cc  -I/usr/include/bsd  prog.c  -lbsd

           The compiler directive -I/usr/include/bsd allows you to write
           portable programs, so do not use a leading ``bsd/'' in #include
           file names:

            #include <bsd/ndbm.h>   /* non-portable */
            #include <ndbm.h>       /* portable, use -I/usr/include/bsd */

The BSD ioctls that Irix supports are not so well documented as the network
and system call BSD compatibility routines, but the rule for <sys/ioctl.h>
is the same as for the network and generic headers.

In no case should </bsd/...> be used, as the leading slash tells cpp to look
for the file by the given absolute pathname.

Important note for all our patient BSD-oriented customers: in the next release
almost all BSD compatibility "goes native."  The /usr/include/bsd tree becomes
a tree of symbolic links to BSD headers in their natural locations (for example
/usr/include/net), and you may elect not to install this compatibility tree.
Almost all (3B) and (3N) routines are in libc; libbsd contains only a handful
of entry points that collide with System V or POSIX routines in libc, and that
cannot be renamed via a required header file so as to coexist in libc.  Perhaps
best of all, Irix implements BSD and POSIX signals.

This means that if you've used the "non-portable" include form (<bsd/ndbm.h>
instead of <ndbm.h> and -I.../bsd), your source has differed needlessly from
its BSD base, and you will need the /usr/include/bsd symbolic link tree in the
next release.  If you've used -I.../bsd as the man page recommends, no source
changes are required and the -I's in your makefiles are useless but benign.

As one who has ported much BSD and Sun code for years into the SGI product,
I've chafed at System V's hegemony over libc and /usr/include, and bemusedly
watched as AT&T has gradually adopted BSD and SunOS features.  But SGI made
a commitment to System V for the 4D series that was strong enough to keep BSD
compatibility in a second-class position, so as to avoid "polluting" System V
name spaces, till now.

Brendan Eich
Silicon Graphics, Inc.
brendan at sgi.com