>Whereas, on the contrary, Peter Seebach has shown up at least one instance
>where our code is _not_correct_ on a K&R compiler,

No, on an ANSI compiler.  In K&R, we never declare the function to take
anything but ints and pointers.  It is only in ANSI-land, with the prototype,
that we declare the function to take a char.  (Then we go back to K&R land and
define it to take an int which acts a bit like a char sometimes, which is why
there is a conflict.)

> As such, I can see no good argument against ANSIfication at as quick a
>rate as is convenient, beginning with new submissions.  As one of many
>people here working from a -current source tree, I at elast would be
>willing to dive depth-first into the ANSIfication of /usr/src as early
>as tommorow.  I think it is clear that we will be better off in the
>long run.

Despite being a big fan of the ANSIfication, I'm inclined to be a bit
slower about it.  I don't think it buys a lot up front, except in a few
cases where we have incorrect code without it.  I would rather wait until
after the June meeting of the C committee; if a decision comes through to
change this so it's no longer incorrect, I'd rather see old-style definitions,
which I think are prettier.  (Of course, then I'm damning compatibility with
C89 systems in favor of C9X, but that's my *job*.)

-s
s