Func Protos with K&R Func Defs

[Steve Summit]

In article <A+-95J6 at xds13.ferranti.com> peter at ficc.ferranti.com (Peter da Silva) writes:
>In article <1991Mar8.204142.14568 at athena.mit.edu> scs at 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 at adam.mit.edu