Dear Scott Wood,
In message 4B031158.20501@freescale.com you wrote:
My question: is there a definitive position somewhere (for example for the Linux kernel; I'm sure we don't have one for U-Boot [yet]), whether system headers should be self-sufficient?
I'd say they should be self-sufficient, in that the inclusion of the header itself should not fail if I haven't included some arbitrary other header. I don't see what the argument would be for not doing this.
Well, Theo de Raadt says for example "... people would be able to include less files; indeed, almost be careless about what they include. But this would not increase portability in any way. And 'make build' would probably, if it was taken the nth degree, take twice as long. Therefore there is no benefit for the crazy rule you suggest..." - see http://www.mail-archive.com/tech@openbsd.org/msg00425.html
I don't know whether Linux has a specific policy on this, but I haven't noticed many problems in this regard, and when I did find one in the kernel a few years back I didn't get any argument when I submitted a patch to fix it.
Which man pages are you looking at?
Well, for example:
open(2): SYNOPSIS #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>
mknod(2): SYNOPSIS #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h>
stat(2): SYNOPSIS #include <sys/types.h> #include <sys/stat.h> #include <unistd.h>
Why do we need these lists of #includes? WHy doe - for example - <sys/stat.h> not auto-include anything it might need?
To me this seems to be an indication that there is no intention to make headers self-sufficent, but I am absolutely not sure.
Best regards,
Wolfgang Denk