[comp.std.c] Parameter mismatch legality question

tim@proton.amd.com (Tim Olson) (11/16/90)

Here is an interesting question that came up recently.  What is the
"legality" of the following ("dusty deck" K&R, not ANSI) code:
	
	foo();
	
	bar()
	{
		int a;
		.
		.
		foo(a);
		.
		.
	}
	
	foo(a, b, c, d)
	int a, b, c, d;
	{
		.
		.
	}

i.e. the call to a function passes fewer parameters than are declared
in the function declaration.

Since C's parameters are "call-by-value", they can normally be
modified or destroyed by the called function.  What if a compiler with
dataflow analysis decided that the lifetimes for the parameter "b" and
a local variable were non-overlapping, and decided to use the same
space (be it memory or a register) to hold them?  In the case above,
it could end up overwriting some local variable from procedure bar()!

So the question is, is the code:

	a) Legal in all cases (at least for K&R C)

	b) Legal if there is no explicit modification of "optional"
	   variables

	c) Illegal

	d) Other?

--
	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)

gwyn@smoke.brl.mil (Doug Gwyn) (11/16/90)

In article <1990Nov15.224353.155@mozart.amd.com> tim@proton.amd.com (Tim Olson) writes:
>		foo(a);
>	foo(a, b, c, d)
>	c) Illegal

henry@zoo.toronto.edu (Henry Spencer) (11/17/90)

In article <1990Nov15.224353.155@mozart.amd.com> tim@proton.amd.com (Tim Olson) writes:
>	foo();

This appears to be meant as a declaration of `foo'; it is not legal as one
in ANSI C.  `int foo();' would be.

>		foo(a);
>	foo(a, b, c, d)
>i.e. the call to a function passes fewer parameters than are declared
>in the function declaration.

In the absence of prototypes, the effect is undefined (3.3.2.2), so your
compiler is entitled to generate code that calls the Soviet embassy, sends
your program, and then tips off the FBI that you are committing espionage.
Or if it's feeling nice, it might give you an error message.

In the presence of prototypes, a number-of-arguments mismatch is illegal
and must be diagnosed.

>Since C's parameters are "call-by-value", they can normally be
>modified or destroyed by the called function.  What if a compiler with
>dataflow analysis decided that the lifetimes for the parameter "b" and
>a local variable were non-overlapping, and decided to use the same
>space (be it memory or a register) to hold them?  In the case above,
>it could end up overwriting some local variable from procedure bar()!

Given the undefinedness of the situation, that is perfectly legitimate.
I would recommend fixing the code.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry