Xref: utzoo comp.std.c:4324 comp.sys.amiga.programmer:861 Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.std.c,comp.sys.amiga.programmer Subject: Re: ANSI prototypes, the right choice... Message-ID: <1991Feb13.105852.540@sugar.hackercorp.com> Date: 13 Feb 91 10:58:52 GMT References: <1991Feb9.075215.26939@athena.mit.edu> <1991Feb11.030811.25074@sugar.hackercorp.com> <1991Feb12.005726.22447@athena.mit.edu> Organization: Sugar Land Unix -- Houston, TX Lines: 42 In article <1991Feb12.005726.22447@athena.mit.edu> scs@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. `-_-' .