On Sun, Nov 03, 2002 at 07:09:19PM +0100, der Mouse wrote:
> > An include question:
> 
> > When I include <sys/syscall.h>, I need to include <sys/types>,
> > <sys/proc.h>, <sys/param.h> ...
> 
> > There are other similar situations in kernel headers.
> 
> Userland headers too.
> 
> > Is there a reason why we don't include the requested headers for each
> > kernel header file?
> 
> Inertia, near as I can tell.
> 
> I consider it a bug in foo.h if a file consisting of just
> #include <foo.h>
> produces compiler errors.  I've been fixing such bugs as I find them,

I personally maintain code which works on other unix-like systems and
according to some network headers (userspace) I had to change the order
of inclusions, and sometimes add a headerfile... I also found this
a strange behavior, as a header file should normally know what it
requires and include it IMHO.

As headerfiles are self-defining a unique symbol to make sure to not
be applied more than once, this avoids portability problems, and even
makes the code cleaner, where obscure headers under a particular API
don't need to be specified where they aren't used (only the common
ones which are obviously required)

A higher-level part of an interface can then be used cleanly, and if need
be, although not required, an application would specifically include
the low-level headers when it needs to access the optional functionality
they provide.
In the case of <sys/types.h> I understand the need to include it nevertheless
for code clarity, but that's because the file requires the standard types it
provides... Of course that's my debatable opinion, although derived from
experience

Hmm this may not be a tech-kern ideal topic, perhaps some clarification
in the style.txt should be made, and source tree migrated accordingly
to decision taken? The same inconsistency is found at various locations
in the tree...

Matt