>> As I understand it, what you are attempting to argue against is the
>> idea that an include file - <stdio.h>, <arpa/inet.h>, <fcntl.h>,
>> whatever - should itself #include anything else necessary in order for
>> it to function correctly.  That's certainly the idea I'm trying to
>> argue for.
>
>To a certain extent, yes.  I don't mind hiding the use of nested
>includes to help build a set of machine independent headers as NetBSD
>has done, but I sure as heck don't like the idea of over-simplifying
>things to their ultimate end as The Single UNIX Specification has done.
>It simply will not work in the real world -- code must still be written
>to run on legacy non-conforming systems.

personally...i'm always finding myself being bitten by the need for
unistd.h for almost all the system calls i ever use (like read(),
write(), lseek(), and close()) *except* open(), which is in an include
file by a different name (along with all the flags that open() needs).
and i use open() a lot more than i use fcntl(). can someone point me
to the standards web page that justifies this?  :(

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."