>  "Charles M. Hannum" <mycroft@gnu.ai.mit.edu> wrote:
>  
>  > 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.

Most of the interfaces defined by <sys/*.h> aren't new, and are either 
described by various standards (POSIX.1, XPG3, SVID, etc) or by common
usage and manpages.  For example, you can't just include <sys/stat.h>
and expect it to work --- you know that <sys/types.h> must be included
first.

People might ask, "But shouldn't NetBSD make it work anyway to make it
easier on the programmer?"  I claim it doesn't make it easier, as it 
makes the program non-portable to systems that strictly follow the 
standards or conventions.

Also including every needed header files adds a great deal of complexity.
Some of the standards that we are attempting to make NetBSD comply require
"clean namespaces".  I think that the added complexity may make that more
difficult to attain.

> Well, I guess I simply disagree.  If something in <sys/resource.h> is
> going to use quad_t, then it really ought to know what a quad_t is.

I am undecided about the case of <sys/resource.h>.  It has not been
standardized (as far as I know), so I consider it covered by existing
conventions.  Historically <sys/resource.h> only required <sys/time.h>
to be included first.  

Most of the time it won't matter, since a program that uses it will usually
be using another function or header file that requires <sys/types.h>, and
(again, by convention) that header is usually #included before other
sys headers.

	--jtc