[cfe-dev] K&R style argument lists and the type system

[steve naroff]

On Aug 25, 2008, at 7:08 PM, Eli Friedman wrote:

> Consider the following testcase:
> int a() {return 0;}
> int b() {return a(1);}
>
> Calling b has undefined behavior per C99, but no diagnostics are  
> required.
>
> Consider the following testcase:
> int a(int);
> int a() {return 0;}
> This is a constraint violation per C99.
>
> We currently map a() to FunctionTypeNoProto, and this has roughly the
> right behavior when we don't merge types.  However, by adding merge
> types, we conclude that a() has type a(int), which is clearly wrong,
> and leads to crashes trying to access non-existent parameter
> declarations.  But if we instead map a() to a FunctionTypeProto with
> no parameters, we incorrectly error out on the first example.
>
> And actually, we already have this problem for cases like the
> following, which are less common:
> int a(x,y) int x,y; {return x+y;}
> int b() {return a(1,2,3);}
>
> Any ideas for how to solve this?  We could always map definitions
> identifier-lists to FunctionTypeNoProto, but that means a good chunk
> of additional code to check type-merging doesn't do bad stuff to a
> definition and allow CodeGen to synthesize the type of such a function
> definition properly.

This makes more sense to me, since there is no prototype for a(x,y).

I think it's better to keep the old style function definition separate  
from the modern syntax/semantics...

snaroff

> Another possibility would be to  add a flag to
> FunctionTypeProto which signifies whether the type comes from an
> identifier list; however, I have no idea where to add such a flag.
> -Eli
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev