>> I consider it a bug in foo.h if a file consisting of just
>> #include <foo.h>
>> produces compiler errors.

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

That's a good example of the sort of thing I mean.

If I use foo_t in my code, I should include the header <bar.h> that
defines it, yes.  But if I happen to use bleeble(), whose interface
does not require me to know foo_t even exists, but bleeble() is
declared in the same include file <fribble.h> as another call gringle()
whose interface _does_ require its caller to know about foo_t, *then*
should I have to include <bar.h>?  I maintain I should not.  Yet in far
too many cases, <fribble.h> produces syntax errors if foo_t is not
already defined.

Also, I believe that in no case should I have to include <bar.h>
*before* <fribble.h>; I believe that if reordering #include lines
changes anything, there is a bug in the include files.  (In a way, this
looks like a consequence of the other position, but it isn't, really;
even if everything <fribble.h> exports requires the caller to know
about foo_t, I still think there's a bug if including <bar.h> after
<fribble.h> changes anything.)

Concrete example: Suppose I use close(), which takes and returns an
int, and I include <unistd.h> to prototype it.  Suppose <unistd.h> also
prototypes fork(), whose interface uses the pid_t type.  Should I have
to include <sys/types.h> to declare pid_t because a function I don't
use and may not even know exists happens to need it?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B