On Tue, 27 May 1997, Peter Seebach wrote:

> >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.)

Well, I think the current contradictory declaration and definition will
_only_ work in GCC, which is what I should have said.  If we compile in
a K&R compiler, we get code which is correct, but cannot be linked with
the output of a conforming ANSI compiler on the same system.

> >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

I agree that going to C9X buys us a lot...  but when will we support   
it?  At any rate, if I understand correctly, C9X will help us clean
up some of our other gcc dependencies, such as long long, which will
be a _big_ win...
    
As far as diving in at daybreak, that's more of an aversion to having   
half of each, but if we clean up the actual incompatibilities, we can
certainly afford to hold out on the rest if need be...

--

				Jim Wise
				jim.wise@turner.com