[Soot-list] Possible bug in PatchingChain.insertBefore(List, Object)

[Henry Falconer]

> > I have an idea that might partially explain this: some of the code I'm
> > inserting contains jumps to 'point' that I want to keep intact after
> > they're inserted. For example, say this block of code, 'toInsert', is a
> > while loop that I've constructed. Before I insert the while loop, I've 
>set
> > the target of the if statement at the top, which represents the loop
> > condition, to the same 'point' that I'm passing to insertBefore(), so 
>that
> > it exits properly when this loop is inserted into the method.
> > insertBefore() now redirects the if statement's target, so that if the
> > loop condition fails, it just jumps back to the loop condition again, so
> > you have an infinite loop.
>
>You can always use insertAfter and redirect jumps yourself or insert
>before and make sure to go back through those units you added and "fix"
>the jumps.

Yeah, that's what I've done, I wrote an alternative insertBefore() as a 
static method in my own code, and then I just call that instead of the Soot 
version. It doesn't use getBoxesPointingToThis(), but goes through the 
target chain looking for Ifs and Gotos, then redirects them if necessary, 
and then uses insertAfter() to insert 'toInsert'. That way, no jumps in 
'toInsert' are ever affected.

>The insertBefore(List toInsert, Unit point) method which takes a list to
>insert reverses that list and then calls the other insertBefore(Unit
>insert, Unit point) for each element in the list.. obviously this will
>redirect any jumps that get added before the last (first) element.

I tried to understand what the Soot code was doing and I thought this part 
was probably the source of the problem. My point is that inserting a while 
loop, or any code with a jump to the insertion point, seems like quite a 
reasonable thing to do - I'm sure I'm not the first person to have tried. 
Don't you think it makes more sense to alter the behaviour in Soot, rather 
than work around it? When the jump redirection is done, surely the expected 
behaviour is to exclude the code you're inserting? I can't think of any 
reason why the alternative would be considered correct.

Henry