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. greez zagi -- 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-unsubscr...@jakarta.apache.org For additional commands, e-mail: bcel-dev-h...@jakarta.apache.org
