cil-users

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

I have a patch for this, but I'm not sure of the right way to offer it.
I'm attaching a file that I hope gets the point across. This enters all
the label names within a function body into alphaTable at the beginning
of processing a function definition.
Aside from fixing the problem I mentioned, this also has the benefit of
having CIL raise an error if there are duplicate label names, rather
than silently allowing them to go through.
Comments are welcome.
-Elnatan
On Mon, 2009-08-03 at 17:43 -0400, Elnatan Reisner wrote:
> 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