Re: Constructor call shadow matches - was: [abc] normal tests (+9f,-9p)

I actually found a way around this by tweaking our must-alias
analysis: When getting two different incoming values (here null, new
X()) we used to assign UNKNOWN. Now I assign just a new value number,
representing that merge. That way, in the following example you can
still decide that y and z are aliased in the following example,
despite the fact that you don't know their exact value (the actual
value does not matter to us).

x = null;
if(p) x = new X();
y = x;
z = x;

That works around the problem we had earlier in a much nicer way.

Eric

On 11/07/07, Pavel Avgustinov <pavel.avgustinov@magdalen.oxford.ac.uk> wrote:
> On Wednesday 11 July 2007 14:36:23 Eric Bodden wrote:
> > The only problem is that this prevents us from applying an
> > optimization to the hottest method in antlr ;-)
>
> Hm, if only you could change the JLS... :-)
>
> > > The fact that many of the failures are
> > > VerifyErrors suggests that soot requires the newStmt and the call to
> > > init to be immediately next to each other, which makes sense (and sounds
> > > familiar -- I seem to recall being told that this is how it should be,
> > > though I'm not sure). If that's the case, and weaving splits the two up,
> > > you'll always have unverifiable code.
> >
> > No that's not true. The matcher requires it. That's why we have the
> > constructor folder. It brings the Jimple code to exactly that shape.
> > In terms of the Verifier it must only be guaranteed that <init> is
> > called on each newly created object before it is used otherwise.
> >
> > > In fact, brief experimentation confirms that adding other code (e.g. an
> > > AssignStatement) in between the newStmt and the init call results in
> > > unverifiable bytecode.
> >
> > Yes, because that's a use.
>
> You're quite right, and I apologise for letting flawed experiments mislead me.
>
> - P
>
>

-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada