>>> 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?

> 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.

That kind of thinking would have us still using punched cards on IBM
mainframes.  There comes a point where an incompatible change must be
made.  The particular change under discussion has the nice property
that a changed system is compatible with old code - which is more than
can be said of many of the changes with tradition that NetBSD has made,
such as POSIX sessions and the infamous setreuid() stuff, which break
existing code that works on pre-change systems.

> Also including every needed header files adds a great deal of
> complexity.

It does?  I've found it's usually one, sometimes two, #include lines in
the affected file.  Hardly rocket science.

> 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.

Doing this doesn't pollute the namespace any more than the existing
requirements already do; it just spares the user having to request the
pollution.  To pick the example that started this thread, since
<sys/resource.h> won't compile at all without quad_t (never mind
_work_), it pollutes the user's namespace with quad_t.  Whether it does
so itself by including <sys/types.h> or whether it requires the user to
do so, presumably by including <sys/types.h>, is irrelevant to the fact
of that pollution.

Mind you, I think it would be better for <sys/resource.h> to use
__quad_t, and include something like <sys/__types.h> which defines
that.  <sys/types.h> would then include <sys/__types.h> and add
additional lines such as "typedef __quad_t quad_t".  Then
<sys/resource.h> would work on its own _and_ not pollute the namespace.

> 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.

We must have different conventions.  The convention I use is that
<sys/types.h> is included after any headers involving fewer than 11
characters between the brackets and before any involving more than 11,
and in no particular order relative to others involving exactly 11.  It
is then the responsibility of each include file - <sys/...> or not - to
include anything else it needs.  Where necessary, this is arranged by
putting copies in my shadow tree.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu