Bug#: 46254

[za...@gmx.ch]

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-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org

Re: Bug#: 46254

[Matthew Wilson <mj...@googlemail.com>]

2009/1/6  <za...@gmx.ch>:
> Hi guys,
>
> The recently opened the bug no. 46254, there I described the problems with dup instructions as insertion points.
<snip>

I can see the argument for using the very same instance for common
instructions (for example, lower memory footprint).  I think that
using Instruction instances as markers within an InstructionList is
possibly misusing the method; BCEL provides InstructionHandle for this
very purpose.  Let me explain my reasoning...

The problem is that this suggestion is making an Instruction both an
abstraction of a byte-code instruction and also a unique instance of
that byte-code within a particular InstructionList.  Compare what Java
does with Strings  If you write "Hello" in one place and "Hello" in
another, they are the very same object.  But if you read the string
"Hello" from a file, it will almost certainly be a different object,
even though it is equal (to the point of being 100% substitutable).
To complete the analogy, two DUP instances are substitutable (IIRC).

Java deals with the ambiguity of identity in places like
List.indexOf() by stating that it finds the index of the "first
occurrence".

I would be against removing all the common instruction instances (for
example, in InstructionConstants).  I would rather suggest that the
insert method's JavaDoc is improved to clarify what it does.  (All
IMHO, of course.)

Kind regards,
Matthew

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