correctcomputation / checkedc-clang

This is the primary development repository for 3C, a tool for automatically converting legacy C code to the Checked C extension of C, which aims to enforce spatial memory safety. This repository is a fork of Checked C's.
14 stars 5 forks source link

Re-running 3C on a converted file results in unexpected behavior #231

Closed sroy4899 closed 4 years ago

sroy4899 commented 4 years ago

Consider the following code in file.c:

int foo(int **p:itype(_Ptr<_Ptr<int>>));

int func(void) {
    int **fp1;
    *fp1 = 1;
    foo(fp1);
} 

After converting once, it results in file.first.c:

int foo(int **p:itype(_Ptr<_Ptr<int>>));

int func(void) {
    _Ptr<int *> fp1 = ((void *)0);
    *fp1 = 1;
    foo(((int **)fp1));
}

After converting file.first.c, two interesting things happen: firstly, the output is different, namely:

int foo(int **p:itype(_Ptr<_Ptr<int>>));

int func(void) {
    _Ptr<int *> fp1 = ((void *)0);
    *fp1 = 1;
    foo(((int **)((_Ptr<int *> )fp1)));
}

(note the extra cast for fp1). Secondly, this output does not appear when you run with the flag output-postfix=. So, for instance, in order to create the file, I ran

cconv-standalone -output-postfix=second file.first.c

but the file that I expected (file.first.second.c) was not created. However, if I run:

cconv-standalone file.first.c

then I get the output I pasted above.

john-h-kastner commented 4 years ago

Sounds like weirdness in cast insertion? That code is definitely a problem area. This might be somehow be related to the cast insertion problem in #160.

sroy4899 commented 4 years ago

Yeah, this is a bit of a compound issue in terms of the cast the second time around and also no output from output-postfix, so feel free to split it as you need. This issue was based on regression test itypecast.c if anyone was curious. It's also the reason why in PR #232 , itypecast.c is marked as BUG.