>> when a header file calls for a variable/definition defined
>> externally shouldn't it then include the file which defines it?
> Plan 9 says "absolutely no under any circumstances",

However, doing this requires that all application code know all about
the internal details of the way the include files are set up, and the
order in which they have to be included, which makes the resulting code
comparatively nonportable (because other systems won't have their files
set up the same way).

Under NetBSD, for example, this would mean that any socket-using
program would need (as of the date of the system on which I'm typing
this)

#include <machine/cdefs.h>
#include <sys/cdefs_elf.h>
#include <sys/cdefs.h>
#include <machine/types.h>
#include <machine/ansi.h>
#include <machine/endian.h>
#include <sys/types.h>
#include <sys/socket.h>

and just how portable would that mess be?

How does Plan 9 deal with this, or does it just shrug and ignore the
issue?  "If it builds under Plan 9, why would you ever want to build it
elsewhere?"  Surely not.

> and as a result, their code does *no* idempotent headers (except for
> ANSI C requirements), and compiles are very very fast.

They need a better preprocessor, one that remembers which include files
are idempotent-protected and doesn't bother rereading them.  gcc's cccp
is documented to do this (and presumably it does so - I haven't checked
it myself)...though like most Project GNU software it tends to be not
especially fast for other reasons.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B