On Wed, May 28, 1997 at 01:37:41PM +1000, matthew green wrote:
> in my own code, i use something similar to __P, and for the functions
> that take a short or a char, i provide to definitions of the function:
> 
> int
> #ifdef __STDC__
> foo(char baz, short bop)
> #else
> foo(baz, bop)
> 	char baz;
> 	short hop;
> #endif
> 
> to deal with this lossage.
> 
> 
> as far as i was able to tell when i implemented this, it's the only
> way to be correct *and* compatible.

Not at the level of separate compilation.  The /only/ way to
be compatible in the sense that a library compiled with an
ANSI compiler can link with code compiled with a K&R
compiler is for the ANSI prototypes never to have types
other than int and double (and maybe long), so that the
promotions will be the same as those that a K&R compiler
would do.

Take the example of an ANSI prototype that takes a float
argument: you can /not/ call that function from a separately
compiled K&R program at all (unless you do something hokey
like passing the float as the int part of an int/float union
in a context where you have not defined the function.)

I'd vote for gradual full ANSI-fication, by the way, on the
grounds that post C9X (or whatever) chances are that /new/
platforms will not have K&R support at all.  If the only
support for K&R syntax is gcc -traditional, then what's the
point?

-- 
Andrew

"The steady state of disks is full."
				-- Ken Thompson