ANSI prototypes, the right choice...

[Peter da Silva]

In article <1991Feb12.005726.22447 at athena.mit.edu> scs at adam.mit.edu writes:
> 	f(i, f, d)
> 	int i;
> 	float f;
> 	double d;

> 	f(1, 2., 3.);

> A simpleminded, incorrect prototype for f such as

> 	extern f(int, float, double);

> could certainly cause trouble,

Certainly. And I'm running into more and more code that does that very
thing, particularly from Lattice-C programmers on the Amiga. Which is
why I brought it up.

> This probably explains K&R2's
> suggestion that "mixtures are to be avoided if possible."

My point exactly.

> Good advice, for those whose code will never see a pre-ANSI
> compiler.  The rest of us have to straddle the fence a bit.

Yes, the other point is "we need a *working* unprotoize that puts casts
into the code, so we can use ANSI prototypes and have a hope in hell
of making them portable.

I've run into other problems with fence-straddling code on older
compilers just for this very reason. It becomes quite painful to
go through and fix every place where people depended on the prototype
instead of casting arguments to functions.

> Followups to comp.std.c; the Amiga folks are probably getting
> sick of this.

It's the Amiga folks who need to pay attention to this.
-- 
Peter da Silva.   `-_-'
<peter at sugar.hackercorp.com>.