> However, I still don't understand this insistence on strict conformance
> with ANSI C.   What's the next step?  Going through the codebase
> and ensuring that there's a protoype in scope for every call to a
> variadic function? 

Yes.  Although I think this is probably already true.  There are cpus
with calling conventions (that NetBSD could conceivably be ported to)
that pretty much require this.  In fact, I think it's a shame that
there are calling conventions that "waste" registers used to pass
function arguments because a varadic functions may be called 
without a prototype in scope.

>  Eliminating "long long", and types that are
> typedef'e to "long long" -- including quad_t and off_t?

No.  I'm inclined to wait to see what if any extended integer scheme
is adopted by the C9X committe.

> I seem to recall hearing that, for example, NetBSD's  stdio library
> wasn't strictly ANSI/posix conformance, because of the use of "long
> long" as a 64_bit off_t.  (off_t, IIRC, has to be an integral type,
> but it's been a long day and I could well be wrong).
> Should we get rid of that, too?

Something like that.  However for ANSI it's fpos_t, which is an opaque
type.  Again, I no reason to change it.  Eventually, it will become a
structure of some time, as it needs to record whether the stream is in
"wide" or "narrow" mode.

> How about eliminating <varargs.h>, and code that uses it?  

If NetBSD ends up on a machine that can not support varargs.h,
obviously we won't be able to support it.  The current scheme of using
stdarg.h or vararg.h depending on whether __STDC__ is defined seems to
work well and I don't see any reason to stop doing it.

> And, personally, I have no time for arguments like ``but that's in a
> system header file, so it's different''.  If the ANSI translator
> gets to see it, and it's not ANSI C, then the program (translation
> unit?) isn't conforming, period.

I agree with this statement.  Code is either conforming or it isn't.

> But - IMHO - when people start jumping up and down and saying "BIND
> is buggy, BIND is buggy", simply because it's not in strict
> conformance with ANSI C, even though BIND is one of the most
> portable and relied-upon pieces of software supporting the Internet
> and the Web -- then the standard has fallen into the hands of people
> who have far, far too much to learn about what makes robust,
> maintainable, correct, reliable, portable C code.  

Just because it's been ported to a zillion platforms and hasn't been
bitten by the problem, doesn't mean it doesn't exist.  When I was in
the porting biz, I quickly found out that it only took one wierd
system to ruin your whole day.  I've thought of a C implementation
with really wonky but legal constraints would be a great test of
portability.

As far as I know, the void main definitions were "harmless" on current
NetBSD systems.  On the other hand, there is no guarentee that it
would be so on all future NetBSD architectures.  It's even conceivable
that we'll make a linkage or calling convention change to the existing
NetBSD ports that would cause programs with void main to fail.

Now that the BIND maintainers have been notified (I suspect multiple
times by now), I think it's time to let this issue drop.

	--jtc