> For instance, a _LOT_ of the user-land code is relatively easily
> portable to system with non-ansi compilers.  that's very useful.

This is a laudable goal but you can't even compile the same
programs on a NetBSD with an ANSI compiler (other than gcc)!
Shouldn't the same standard apply to include files as well?
If we can't test this portability on NetBSD how can we meet
this goal?  Try compiling with lcc (on machines supported by
it) and see[1].

Perhaps a better guideline may be to make sure that a
program compiles with a non-ANSI as well as a strict ANSI
compiler and in the latter case it uses stricter type
checking (modulo cases like char, short & float arguments).
Use of GCC extensions should be strictly for performance
enhancements.

> As for the kernel, some people have been known to compile it in weird
> cross-compilation environments (e.g. me 8-).  Having lots of ansi-isms
> scattered throughout the system makes that harder.

Doesn't Mr. me 8- have to use gcc in these environments?
How does ANSI-isms make the x-compile harder?  Since you are
not going to run the kernel on other systems, you can make
it fully ANSIfied and prevents dumb errors.  For .c files
that use gcc's asm extension, usually it is possible to
provide a slower but pure C version.

> Eventually, there should be a "flag day" when the entire system goes
> to ANSI prototypes, etc. etc. etc. by default.  However, i don't think
> that day has come yet.

One option is to religiously use cond. compile on function
definitions as well so that you can get the benefit of an
ANSI compiler's stricter type checking.  When the flag day
arrives you can just throw out the ugly prototype related
macros.

Yes, this is grunge work but cproto like tools make it
quite a bit easier.

--bakul

[1] I stuck a copy of lcc on alpha.ai.mit.edu in the
incoming dir. for Charles; it may be still there.  If not, I
can mail a copy to whoever wants it or upload it somewhere.