>> >> Any new NetBSD port is likely to make more use of gcc and
>> >> cross-compiling than it is to use a native compiler, no?
>> >> And any counterexample that comes up is more than likely to have an
>> >> ANSI-capable compiler as the native one by now...
>> >
>> >What about people that pick pieces from the code and use it in different
>> >environments?  Like e.g. using the networking code to fix bugs in legacy
>> >machines' tcp/ip implementations.

The code in NetBSD will not drop into any other unix derivative
cleanly.  It will require some work, some of which may be nontrivial.
Deansification is relatively easy; there are tools to do it for you.

>> I totally agree here. I am using pieces of the tree on machines where the
>> native compiler is not ansi [SunOS].

gcc is a better compiler than then SunOS native one.  And, as above,
you can use unprotoize if you have to use the vendor compiler.

>> > It doesn't make a lot of sense to me that we have to be backwards
>> > compatible to older compilers when we will never compile NetBSD with anything
>> > but the Gnu compiler that it comes with.
>> 
>> This assumes that one would have to compile (and quite probably test) gcc
>> on a new target platform before starting a NetBSD port.  I'd consider it
>> inadvisable, at least.

No, it simply means you need to have an ANSI compiler.  ANSI is 8
years old, which is approximately forever in computer time.  The
chance you will not have an ANSI compiler is very small.  IMHO, the
risk is worth the benefit.  gcc has already been ported to practically
everything which it can run on, and new hardware comes with ANSI
compilers.

I think we should optimize our style for NetBSD's use.  If this makes
using the code elsewhere substantially more difficult in a lot of
cases, we should consider that, too.  However, making our code better
at the cost of a little more work for a few people seems like a good
tradeoff to make.

		Marc