CIL doesn't check the uniqueness of label names it uses when unfolding
short-circuiting boolean operators. This can lead to problems if you
already have a label named "_L" in your program. I've attached a tiny
example that gets converted from a stupid but harmless program into a an
infinite loop because of this.
I haven't yet managed to figure out all of the pieces involved in CIL's
handling of labels, so if someone can suggest a fix for this, I'd
appreciate it.
On a related (but not functionally problematic) note, is there a reason
inserted gotos have their location marked as unknown, rather than as
being the same as that of expression from which they originate? More
specifically, Cabs2cil.compileCondExp creates gotos with the line
(gotoChunk lab lu, consLabel lab sf !currentLoc false)
where "lu" is locUnknown. Is there a reason this shouldn't be "!
currentLoc" instead?
-Elnatan
int main() {
int x = 1, y = 0;
_L:
if (x && y); else lbl:;
return 0;
}
/* Generated by CIL v. 1.3.7 */
/* print_CIL_Input is true */
#line 1 "/fs/junkfood2/elnatan/symexe/trunk/cil/setest/labelError.c"
int main(void)
{ int x ;
int y ;
{
#line 2
x = 1;
#line 2
y = 0;
_L:
#line 4
if (x) {
#line 4
if (! y) {
goto _L;
}
} else {
}
#line 5
return (0);
}
}
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users
