>> Two of the main()s that were changed recently was named/ns_main.c and
>  named-xfer/named-xfer.c.
>I have reported that bug to the maintainer of BIND.

Thank you. That's the most productive thing to come out of this.
I would have, but I simply haven't  gotten around to it yet).
Tho' I don't agree that it's necessarily a "bug" to not be in strict
conformance with ANSI C, unless something _claims_ to be.

>No, it tells both the compiler and future maintainers that the programmer
>did not understand the ANSI/ISO C Standard, or deliberately chose not to
>write code for a hosted standard C environment.  Comments might help
>future maintainers tell which of the two cases hold. 

Or, I might add,  that the codebase in question predates ANSI C.
As far as I'm aware, ANSI and ISO standardization of C hasn't quite
yet succeeded in mandating pre-ANSI C out of existence, or in updating
or replacing all pre-ANSI compilers.  There's still a (pre) C language
(though dying) and most (ANSI) C implementations support it, modulo
preprocessor differences. [C++ is perhaps the biggest exception.]

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?  Eliminating "long long", and types that are
typedef'e to "long long" -- including quad_t and off_t?

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?

How about eliminating <varargs.h>, and code that uses it?  Or any other GCC
extensions elsewhere in the NetBSD source tree?  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.

Some of us actually *do* know C, and ANSI C (and even 6 and 7th
edition C) and once upon a time, didn't always assume "void *" was
portable.  That leaves at least  me with the view that standards
are a useful thing to have.  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.

This should be the last thing I say about this issue.