[Soot-list] JimpleLocal.equals()

Patrick Lam p.lam at ece.uwaterloo.ca
Mon Jan 28 16:04:40 EST 2013


Version control history shows me that Ondrej made that change in 2003:

plam at polya:~/soot-svn/src/soot/jimple/internal$ svn log -r705
------------------------------------------------------------------------
r705 | olhota | 2003-03-02 18:14:13 -0500 (Sun, 02 Mar 2003) | 3 lines

Bug fix: equivTo on JimpleLocal's and BafLocal's should be object equality
svn merge -r 703:704 $SVN/branches/1.2.5.dev.8

I'm not sure why this is the case. Maybe Ondrej remembers. It was 9 
years ago though.

pat

On 01/28/2013 03:04 PM, Michael Faes wrote:
> Hi everyone,
>
> I'm currently having problems with the implementation of
> JimpleLocal.equals() and equivTo():
>
> /**
>    * Returns true if the given object is structurally equal to this one.
>    */
> public boolean equivTo(Object o) {
>       return this.equals( o );
> }
>
> While the Javadoc says that structural equivalence is tested (which is a
> sensible thing to do), actually object identity is tested, as the
> equals() method is not overridden (which does not seem to be so
> sensible). In addition, the hashCode() method is overridden in a
> structure-based way, which (is legal but) makes even less sense to me.
>
> Does anybody know if there is a reason for all this or can I safely
> replace the current equals method with a structure-based one?
>
> Thanks for your time.
> Michael
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



More information about the Soot-list mailing list