Subject: Re: problems with arpa/inet.h
To: None <current-users@NetBSD.ORG>
From: Mike Long <firstname.lastname@example.org>
Date: 06/16/1998 16:23:43
>Date: Tue, 16 Jun 1998 12:23:59 -0400 (EDT)
>From: email@example.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,
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
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