[Soot-list] clone implementations in Soot

[Wouter De Borger]

ja, dat zit in /proc/devices welke hij eigenlijk gebruikt

W

On Dec 15, 2007 3:11 PM, Eric Bodden <eric.bodden at mail.mcgill.ca> wrote:

> Hi, Oege. I did a study on exactly that problem for my class on
> Software Architecture:
>
> http://www.sable.mcgill.ca/~ebodde/genclone/<http://www.sable.mcgill.ca/%7Eebodde/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
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20071216/0a781b8e/attachment.htm