[Soot-list] Bug (and fix?) in FastHierarchy

[Eric Bodden]

Hi Michael.

The following seems to make sense to me:

                    if( concreteType.declaresMethod( methodSig ) ) {
                        SootMethod method = concreteType.getMethod( methodSig );
                        if ( isVisible(concreteType, m) ) {
				if (method.isAbstract())
					throw new RuntimeException(...);
				else {
				    ret.add( concreteType.getMethod( methodSig ) );
				    break;
				}								
			}
                    }

What do you think?

Eric

On 8 February 2013 09:28, Michael Pradel <michael at binaervarianz.de> wrote:
>> In your example,
>> shouldn't the algorithm resolve the call to A.m()? If I just remove
>> the check I think it would resolve to B.m() instead, which indeed
>> would be wrong. So I guess instead one would have to cause it walk
>> further up the hierarchy, no?
>
> For my example, it gets resolved to A.m() because of the visibility
> check. But I think you're right in general. Maybe one should replace
>
> if ( isVisible(concreteType, m) ) { .. }
>
> by
>
> if ( isVisible(concreteType, m) && !isAbstract(method) ) { .. }  ?
>
>
> Michael
>



-- 
Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt