>> Then there was the time I tried to get .h files fixed when they
>> didn't include files they needed.  (I got a bald "not a bug, won't
>> be fixed".)
> Yes, this is a standards issue.  It would be a namespace violation
> for a header to define symbols it is not supposed to, and not all
> headers are supposed to be standalone.

Many of the relevant .h files are not standardized headers.  (A simple
example from my patch tree is the SPARC <include/fbio.h>.)

As for the ones that are, well, if a standard specifies <foo.h> and
specifies that <bar.h> must be included first, I believe the standard
is broken and should in that regard be ignored; one cannot use <foo.h>
without having <bar.h>'s symbols intruding on one's namespace anyway,
so there is no practical difference.

Not that I necessarily expect NetBSD to agree with me on this latter
point.  But there certainly are plenty of includes whose fixing would
not run into standards-conformance issues.

/~\ 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