Subject: K&R vs. ANSI call conventions (was Re: a new KNF)
To: <>
From: Todd Vierling <tv@pobox.com>
List: tech-toolchain
Date: 02/15/2000 16:16:49
[Moved to tech-toolchain, as this has strayed from KNF formatting issues
into actual implementation issues.]

: I wish there were a way to have gcc warn when an ANSI prototype would
: promote differently in K&R mode.

The funny thing is, we are already using a completely broken ABI, from K&R's
perspective.  GCC has been generating ANSI-assuming code all along, simply
because we're prototyping all of them (-Wstrict-prototypes, y'know...  ;).

"gcc -s" the following:

=====
	#include <sys/cdefs.h>

	short convert1(f)
		float f;
	{
		return f;
	}

	short convert2 __P((float));
	short convert2(f)
		float f;
	{
		return f;
	}

	#ifndef __STDC__
	short convert3(float f)
	{
		return f;
	}
	#endif
=====

In K&R, the float argument must be promoted to double before calling one of
these functions.

Out of the above, gcc will only generate a "fixdfsf" (convert double to
float) instruction for convert1(), even though the function definition is
the same as for convert2().  gcc is assuming, by the presence of the ANSI
prototype, that the convert2() function will be called with an actual float,
and not a double.

This is fine for an ANSI compiler, as long as no header file defines an ANSI
prototype for convert1() that is _not_ seen by this file.  But, assuming the
above was compiled with gcc and part of a library, a K&R compiler will lose
on convert2(), as it will promote the argument to double, making an argument
twice as wide, and likely in the wrong float format.

This doesn't show up as readily when dealing with integers, because gcc
seems to be a little more careful about truncating integers before subtracts
and divides.  But the fact remains, our ABI is _already_ ANSI.

-- 
-- Todd Vierling (tv@pobox.com)