Subject: Re: problems with arpa/inet.h
To: None <current-users@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 06/14/1998 12:04:04
[ On Tue, June 9, 1998 at 08:27:23 (-0500), email@example.com wrote: ]
> Subject: Re: problems with arpa/inet.h
> I'm slowly coming to agree with the "no multiple inclusion" crowd. Rob
> Pike is probably the most eloquent on this issue...
Indeed. Nested includes are *evil*. Unfortunately we'll never get away
from them with the current unix APIs.
In fact if you read the Single UNIX Specification, Version 2, you'll
find that they've chosen to go 100% with nested includes. I'd bet that
when using any sufficiently sophisticated interface under their API that
you'll end up including nearly every single header file in the system,
even if all you do in the end is write the equivalent of hello.c.
Life this way isn't as bad as it once was. Once upon a time I worked on
MS-Windows 1.x and 2.x to pay the rent. There you had <windows.h>,
which defined well over 3000 manifest constants, and a good 500-600
prototypes, etc. They ended up having to supply lots of #ifdefs to
allow one to eliminate unneeded portions of that monster header file
that included many other nested includes. If you didn't do that the
publicly available versions of the MS-C compiler they were shipping at
the time would blow their top because their internal limits were "too
small". Because none of this was well documented you had to figure out
all of this crap on your own too.
Unix has nearly joined the Windows' way of programming.....
Personally I'd rather that I have to specify 42 include files at the top
of my module. It's either that or we could have one header per lib*.a
Greg A. Woods
+1 416 443-1734 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>