Re: RFC/RFHelp: c-decl.c rewrite - almost but not quite

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Tue, 16 Mar 2004, Dale Johannesen wrote:

> How do you make that out?  Here's the language:
> 
> If the expression that denotes the called function has a type that does 
> not include a prototype,
> the integer promotions are performed on each argument, and arguments 
> that have type float
> are promoted todouble. These are called the default argument 
> promotions. If the number of
> arguments does not equal the number of parameters, the behavior is 
> undefined.
> 
> I don't see anything about run time vs compile time there.

The standard never explicitly states whether it is compile-time or
run-time undefined.  It's meant to be "obvious" in each case.

To avoid the question of whether empty parameter lists give prototypes,
consider the case:

int f(a)int a;{return 0;}
int g(a,b)int a,b;{return 0;}
int z;
int h(){return (z?f:g)(1);}

If z is nonzero, the call is to f and there is no undefined behavior.  If
z is zero, the call is to g and there is undefined behavior.  The
expression (z?f:g) is evaluated at runtime every time and the program has
undefined behavior in a particular execution if it evaluates to g at some
point during that execution.  If it always evaluates to f, there is no
undefined behavior from this particular cause.

Now, *every* function call is conceptually like that in ISO C - the
expression denoting the called function is a function pointer evaluated at
runtime.  Compilers of course optimize the case where that expression just
names a function (and shared library issues deoptimize it because the
function you see might be overridden at runtime in certain cases), but
this doesn't mean that the call will happen at all.  g(1) is not a
constraint violation; if h is not called, it is just as OK in standard
terms as the call to (z?f:g) as long at that never evaluates to g.  
(Practically, a mandatory warning, not a pedwarn, and a compilation to an
abort, would make sense, just as we do in the case where there are
prototypes but the function pointer has been cast to an incompatible
pointer type before the call, which has the same property of run-time
undefined behavior if the call is executed.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk