> >>> This patch is bogus.  If you're going to include things from sys/,
> >>> it's *your* problem to insure that any files they depend on are
> >>> included.  Adding includes like this is a slippery path to Hell.
> > In general, I agree with this.
> 
> Okay, what's _your_ take on what's wrong with it?  As I noted, I've
> been doing effectively this for years, and haven't had any trouble yet.
> So what am I setting myself up for?

Bad dependency lists on stupid hardware are a big problem you'll run
into.  This will also cause you to lose track of sometime important
changes that occur in unseen include files when your include files start
including the world.  I see this alot at work by certain programmers who
try to make everything work in one include file.  This bites them when
stuff changes, and they don't notice the changes.  Most of the time a
good compiler will pick it up, but we don't have access to a good
compiler. ;( [Funky hardware with a propriatary piece of crap compiler]

But, as with every rule there are exceptions.  The biggest exception to
this is what the man page says.  If the man says you need <sys/types.h>
and <sys/socket.h>, it better be enough.  If those include files are all
that is required in documentation, then they better include any other
files needed to guarantee all names and symbols are resolved.



Nate