Re: gcc/gcc/cp ChangeLog dump.c

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > To correct a widespread error of fact -
 > 
 > It is perfectly okay to have functions that must be K+R compatible
 > return bool (alias char).  The return type declaration is visible to
 > both K+R and ISO compilers, and K+R compilers will do the Right Thing
 > with them.

That is correct.


 > What does not work is to have a K+R compatible function with a 
 > FORMAL PARAMETER of type bool.  A K+R compiler will miscompile the
 > call site in that situation, since it does not know the types of the
 > arguments.
 > zw

I believe you're wrong here.  True K&R handles bool (if aliased to
char) just fine in function parameters.  In both the call site and the
function definition, char is promoted to int so there is no problem.

The breakage happens in ISO C when you prototype a char argument but
use old style function definitions.  Then the call site becomes (or
remains) char but the definition uses int.  GCC (and I think some
other C89 compilers) accept this as an extension under the assumption
that if the definition also sees the prototype, then it doesn't do any
promotion and uses char width for the definition.  But that assumes
your definitions always see the prototype.  In GCC sources we do a
good job these days with prototypes, but it isn't always true for all
code out there.  Perhaps that's why C89 doesn't include this feature.

Anyway once we move the entire source base to ISO C style function
defintions, all of this confusion will go away.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu