As Elnatan said, there are additional concerns with functions with an
incomplete prototype.  However, I believe there is actually a second bug
related to these.

The "compiling to C" section says "Prototypes are added for those functions
that are called before being defined. Furthermore, if a prototype exists but
does not specify the type of parameters that is fixed."

While this is arguably nice (and arguably bad, as it may smooth over
possible errors in the original source), it doesn't go the whole way into
fixing the problem.  It does fill in the prototype, but it does not then add
appropriate explicit casts to the code.  For example:

int f();
int main(void){
    char x = 5;
    f(x);
    return 0;
}
int f(unsigned long long int x){
    ...
}

Cil turns the above into:

int f(unsigned long long x ) ;
int main(void) {
  char x ;
  x = (char)5;
  f(x);
  return (0);
}
int f(unsigned long long x ) {
  ...
}

The problem is that now, as it is written, although f does have a proper
prototype, the call to f() does not have the appropriate explicit conversion
to unsigned long long.  (We see the same behavior if we simply leave out the
incomplete prototype entirely.)  It should be
  x = (char)5;
  f((unsigned long long)x);
Indeed, this is what you get if you complete the prototype to "int
f(unsigned long long int);" and run it through CIL again.

Possibly it shouldn't be creating/replacing the prototypes as written (in
which case it should be performing default argument promotions according to
6.5.2.2:6 (9899:201x)).  Since I presume this is desired behavior for some,
the explicit casts are then simply missing.  It should either act as if the
complete prototype were there to begin with (and therefore explicitly cast),
or not change the prototype at all (and therefore explicitly promote).  I
see this as a similar, but separate bug from the variadic function bug from
earlier.

Any thoughts?  Is my understanding of the spec and CIL's behavior correct?

-Chucky



On Fri, May 21, 2010 at 2:02 PM, Elnatan Reisner <elna...@cs.umd.edu> wrote:

> On May 21, 2010, at 12:30 PM, David Gay wrote:
>
> On Fri, May 21, 2010 at 9:11 AM, Elnatan Reisner <elna...@cs.umd.edu>
> wrote:
>
> On May 20, 2010, at 1:10 PM, Chucky Ellison wrote:
>
>
> I've noticed some argument promotions that seem not to have been made
>
> explicit.  In the code:
>
>
> int testDifferent(int x, ...);
>
>
> Aside from ellipses in function prototypes, CIL also exhibits this behavior
>
> when functions are declared with no prototype, as in:
>
> void f();
>
>
> See bullet 6 in the "Compiling C to CIL" section of the CIL
> documenation at http://hal.cs.berkeley.edu/cil. In a nutshell, CIL
> rewrites prototypeless funcrtion declarations to have a prototype
> (when possible). I'm pretty sure said prototypes follow the implicit
> conversion rules...
>
>
> Yes, CIL rewrites the function declarations to have a prototype, but it
> does not insert corresponding casts at the function calls.
> For example:
>
> void f();
> int main() {
> short x;
> f(x);
> return 0;
> }
> void f(int x) { }
>
> when passed through CIL becomes
>
> void f(int x ) ;
> int main(void)
> { short x ;
>   f(x);
>   return (0);
> }
> void f(int x ) { return; }
>
> Notice the lack of an explicit cast in the call to f(x). However, if you
> change the first line of the original program to 'void f(int);', then the
> cast is inserted, but the output is otherwise identical.
>
> Elnatan
>
------------------------------------------------------------------------------

_______________________________________________
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users

Reply via email to