Func Protos with K&R Func Defs

[Steve Summit]

In article <USY9_VA at xds13.ferranti.com> peter at ficc.ferranti.com (Peter da Silva) writes:
>This means, then, that an ANSI compiler is allowed to make the sorts of
>optimisations that prototypes allow it to safely make, without the prototypes
>being in scope?

Some of them.  If no prototype is in scope during a function
call, a compiler:

     1.	should use a calling convention which assumes a fixed
	number of arguments, if there is a different convention
	which is used for functions with a variable number of
	arguments;

     2.	must perform the "integral promotions" (char and short to
	int) and promote float to double (see ANSI X3.159 section
	3.3.2.2), and must therefore not use any special "narrow"
	argument passing conventions; and

     3.	may pass values in registers (as opposed to "on a
	stack," if this distinction even means anything) as long
	as doing so does not conflict with 2.

All of this can be deduced from language in the Standard, which
(though verbose and occasionally convoluted) is quite
unambiguous.

>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 rules relating prototyped and old-style
functions are somewhat complicated, but they make sense, and are
formulated correctly to allow maximum interoperability (and, yes,
portability) between the two forms.  Given the desire to adopt
prototypes at all, no other decisions could have (consistently)
been made, other than perhaps to disallow old-style functions
altogether.

More reruns (in a futile attempt to hammer the point home):
Old-style functions may be assumed to be fixed-argument.  (This
is actually consistent with the original definition of C; printf
has always been an anomaly.)  A compiler may (and in fact,
should) use its efficient calling sequences when prototypes are
not in scope.  The variable upon which to base the choice of
function-call linkage is not the presence or absence of
prototypes, but the presence or absence of variable-length
argument lists.  (I suspect that it is a misunderstanding of this
point that is causing the confusion.)

Also, to repeat what Chris just said (with a quote from an
earlier article of mine):

The statement

> The compiler
> might generate a different calling sequence for prototyped functions because
> it knows the argument count.

is quite misleading.  The correct statement is

	The compiler might generate a different calling sequence
	for a function prototyped with an ellipsis, because it
	does NOT know the argument count.

If there are still questions on any of this, please send mail; I
think enough has been posted on this by now.

                                            Steve Summit
                                            scs at adam.mit.edu