[Soot-list] clone implementations in Soot

[Eric Bodden]

Hi, Oege. I did a study on exactly that problem for my class on
Software Architecture:

http://www.sable.mcgill.ca/~ebodde/genclone/

I even have a version of Soot (little outdated now) that uses clone()
properly. Maybe I should check that in after Christmas. It was not at
all easy to get right because there are classes in Soot where you want
non-default semantics (e.g. you want "this" to be returned for
Constants).

Eric

On 15/12/2007, Oege de Moor <Oege.de.Moor at comlab.ox.ac.uk> wrote:
>
> While playing around with Soot in SemmleCode, I noticed there
> are two places where executing the clone method will definitely
> lead to a class cast exception:
>
> PointsToBitVector.clone()
> MonitorSet.clone()
>
> The reason is that in both these cases, the object is constructed
> by calling super.clone, but the super class just calls one of
> its own constructors, instead of also calling super.clone.
> It is bad practice to do that in implementations of clone,
> and indeed the doc of java.lang.Object.clone() states:
>
> "By convention, the returned object should be obtained by calling
> super.clone. If a class and all of its superclasses (except Object)
> obey this convention, it will be the case that
> x.clone().getClass() == x.getClass(). "
>
> The SemmleCode query to find the above two bugs is
>
> ------------------------------------------------
> predicate isclone(Method m) {
>     m.hasName("clone") and
>     m.hasNoParameters() and
>     not m.hasModifier("abstract")
> }
>
> from Method c, Method sc
> where c.fromSource() and
>        isclone(c) and
>        isclone(sc) and
>        c.callsSuper(sc) and
>        not sc.getDeclaringType().hasName("Object") and
>        not(exists(Method ssc | isclone(ssc) and sc.callsSuper(ssc)))
> select c.getDeclaringType().getPackage(),c.getDeclaringType(),c
> -------------------------------------
>
> Probing a little further, the following query demonstrates that
> there are 504 places in Soot where the same problem is
> waiting to happen:
>
> -------------------------------------
> from Method c
> where c.fromSource() and
>        isclone(c) and
>        not exists(Method sc | c.callsSuper(sc) and isclone(sc))
> select c.getDeclaringType().getPackage(), c
> -------------------------------------
>
> That is, it finds 504 implementations of "clone" that do not
> make a "super.clone" call.
>
> To put that in perspective, there are 4 implementations of "clone"
> in abc exhibiting the same problem, all in the around weaver.
>
> In all of polyglot (including the extensions distributed with it),
> there are 12 such suspicious clone methods.
>
> I learnt of these queries from Julian Tibble; variations of them
> are included with the distribution of SemmleCode.
>
> Is anyone game for collaborating on a library of coding conventions
> for Soot?
>
> DISCLAIMER: I'm the CEO of Semmle Ltd, the company that produces
> SemmleCode, so this message is a shameless product plug. The product
> is free, however...
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>


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