Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: Func Protos with K&R Func Defs Message-ID: <1991Mar12.052025.18801@athena.mit.edu> Date: 12 Mar 91 05:20:25 GMT References: <1991Mar8.204142.14568@athena.mit.edu> Sender: news@athena.mit.edu (News system) Reply-To: scs@adam.mit.edu Organization: Thermal Technologies, Inc. Lines: 74 In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Mar8.204142.14568@athena.mit.edu> scs@adam.mit.edu writes: >> >This seems to rather the optimisations that an ANSI compiler >> >can make... > >> There's a missing, so I can't figure out what comment this makes >> on ANSI prototypes. > >The missing is "limit", you should be able to that from context. Just >at the sentence for a while, and it will make. It didn't. (The word might as easily have been "augment.") I still don't understand how prototypes can be thought to be less useful, or the optimizations which they permit less potent, just because some of the optimizations are also permitted (and implicitly required) even in the absence of prototypes. (If someone wants old programs, which implement variable-length argument lists without using ellipses, to keep working, that would have some additional bearing on the choice of implementations and optimizations, but those programs are *not* required to work, and no one is doing anybody any favors by coddling them.) >Perhaps there should be a lengthy and detailed discussion on this in >the std or an associated docco, It may not be lengthy and detailed, but I think there's adequate documentation right there in the Standard. When I was quoting chapter and verse in several earlier articles on this subject, I forgot to check the Rationale, which makes the same point I was making, quite explicitly (Rationale section 3.3.2.2, discussing compatibility between prototyped and non-prototyped declarations of functions with no "narrow" types and no variable argument lists): This provision constrains the latitude of an implementor because the parameter passing of prototype and non- prototype function calls must be the same for functions accepting a fixed number of arguments. Implementations in environments where efficient function calling mechanisms are available must, in effect, use the efficient calling sequence either in all "fixed argument list" calls or in none. >because of the compilers that get it >wrong and all the folks who are having so much trouble writing code >that satisfies both sides. I sure haven't found the balance yet. If there are compilers getting this wrong, let's get 'em fixed now, before they induce too many people to write incorrect code. Name names here, or in comp.std.c, if you have to. I think "the folks who are having so much trouble writing code" are, for the most part, making their own lives miserable by insisting on trying to declare "narrow" arguments -- char, short, and float. "Doctor, doctor, it hurts when I do that!" "Well, then don't do that." If you steer clear of narrow arguments, you can code away to your heart's content, rarely worrying about whether declarations and/or definitions use old-style or prototype syntax. (There are two exceptions. First, functions with variable-length argument lists must be defined using prototyped syntax, and must be called with prototyped declarations in scope. If the code is to be portable to pre-ANSI compilers, #ifdefs are required in both declarations and definitions of varargs functions. Second, it may be important to emphasize prototyped declarations to help insure correct calls, if lint is not available or is not being used.) What other cases are there that it's hard to find a balance for? Steve Summit scs@adam.mit.edu