jakarta-bcel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zagiatakrapo...@gmx.ch
Subject Bug#: 46254
Date Tue, 06 Jan 2009 15:03:25 GMT
Hi guys,

The recently opened the bug no. 46254, there I described the problems with dup instructions
as insertion points.
Now I have discovered that this bug has much more impact than I had thought before. It occurs
with every constant instruction like dup, iconst etc. .
Try to add a new instruction after an iconst instruction, if there are several iconst instructions
your inserted instruction will be added in the WRONG place!
I think this is a severe issue and im wondering whether you guys know this problem, you never
had such a testcase or if I am using this framework completely wrong.

try this:

init:       i1, i2, i3, iconst_5 i4, i5, const_5 (2), i6

1.)  insert(i3, new_i)
result:  i1, i2, new_i, i3, iconst_5, i4, i5, iconst_5 (2), i6

2.) insert(iconst_5, new_i2)
result:  i1, i2, new_i, i3, new_i2,  iconst_5, i4, i5, iconst_5 (2), i6

3.) insert(iconst_5 (2), new_i3)
result:  i1, i2, new_i, i3, new_i2, new_i3, iconst_5, i4, i5, iconst_5 (2), i6

the insertion should be done after i5, but because the framework compares refrences to find
the insertion point, and all constant instructions are references to the same object, the
first match is taken. According to my opinion  this is completetly wrong!

What I have to do now is a workaround: I iterate over the whole instruction list and I replace
every constant like dup and iconst with a new instance for each such match. That really ugly.

Maybe you can tell me why the framework uses only one instance for every dup instruction in
an instruction list of a method.



Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org

View raw message