>Date: Tue, 16 Jun 1998 12:23:59 -0400 (EDT)
>From: woods@most.weird.com (Greg A. Woods)
>
>[ On Sun, June 14, 1998 at 23:10:11 (-0400), der Mouse wrote: ]
>> Subject: Re: problems with arpa/inet.h

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

I'm with Greg on this one.  If you're writing a 'hello world' program,

#include <stdio.h>

should be the only header required.  However, if you're using
inet_ntoa() then I see no reason why you should not be required to use

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

because that's the way <arpa/inet.h> has traditionally been used.

Standards are tradition codified; where they get ugly is when you have
multiple conflicting traditions.  If you can point to any mainstream
UN*X implementation more than a couple of years old that doesn't
require those other three headers before <arpa/inet.h>, then I might
believe you have some justification for modifying <arpa/inet.h> to
include them itself.  Otherwise, it isn't broken and you shouldn't try
to fix it.
-- 
Mike Long <mikel(at)shore.net>             http://www.shore.net/~mikel
"Every normal man must be tempted at times to spit on his hands,
hoist the black flag, and begin slitting throats." -- H.L. Mencken