Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.c Subject: Re: Func Protos with K&R Func Defs Message-ID: Date: 6 Mar 91 17:31:08 GMT References: <1991Feb28.021715.18153@athena.mit.edu> <15354@smoke.brl.mil> <1991Mar2.181953.15401@athena.mit.edu> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 49 In article <1991Mar2.181953.15401@athena.mit.edu> scs@adam.mit.edu writes: > Doug's statement is true, without exception, and reflects clear > language in X3.159 (which I have quoted from in two previous > articles on this subject), which defines exactly what is required > for two function types to be compatible. So you're saying that the compiler is not allowed to take advantage of the prototype information and use (for example) callee saves or special LINK instructions when calling prototyped functions? This conflicts with... > Secondly, there is no reason to use > the less efficient calling sequence for old functions; the > "newer," presumably more efficient (though not admitting of > variable numbers of arguments) calling sequence can and should be > used. I don't believe this statement is true. If there is no prototype is in scope, the compiler cannot make any assumption about the calling sequence: it may be dealing with older code that uses a pre-ANSI method of handling variadic functions, for example. For that matter the customer might be working with older, pre-ansi libraries without source code available. > Efficiency is, after all, the most important > consideration, and the main reason prototypes were adopted. > (Don't buy this line that they're for checking function call > consistency across source files, "for your convenience." If > they're for your convenience, then why do you have to work to > supply them?) It's not just a matter of "convenience". You need to have function prototypes to generate correct code in the general case, due to (among other things) the common use of uncast null pointer constants in function calls and other vaxisms that depend on sizeof(int) == sizeof(char *). Every other algol-type language I know of, even the execrable PL/M, does require full prototypes for all functions. The compromise in ANSI C is a reasonable compromise with current usage, and a long-needed enhancement to the language. In an environemnt where things like X-windows are accepted as the best that we can do, efficiency arguments for prototypes must be taken with a grain of salt. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"