Re: maybe a semantic mistake?

[Ondrej LHOTAK <olhotak@sable.mcgill.ca>]

The lookup code implemented in Soot follows the description given in the
Java Virtual Machine Specification, under invokevirtual:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions2.doc6.html#invokevirtual

According to this description, for the example you gave, the A.f() that
Soot returns would indeed be the correct method to invoke. Contrary to
your claim, it is *not* true that C cannot access any f(), neither from
A nor B.

If you still think I have misunderstood the specification, please let me
know.

Ondrej

On Thu, Mar 06, 2003 at 11:17:21AM -0500, Weilei Zhang wrote:
> The following is from the method resolveConcreteDispatch in Hierarchy.java.
>  public SootMethod resolveConcreteDispatch(SootClass concreteType, SootMethod m)
>     {
>     .......... 
>         while (it.hasNext())
>         {
>             SootClass c = (SootClass)it.next();
>             if (c.declaresMethod(methodSig) 
>             && isVisible( c, m )
>             ) {
>                 return c.getMethod(methodSig);
>             }
>         }
>     ......
>     }
> I think the loop should be terminated once we find a SootClass c s.t. (c.declaresMethod(methodSig)&& ! isVisible( c, m )). 
> The reason is as follows: think of a Class A ,which has public method f(), Class B which extends A and has a redefined private method f(), Class C extends B and doesn't redefine method f(). Then the instance of C can't access any f(), either in A() or in B(). But in your code, A.f() will be returned.
> However, the case I mentioned can't appear in normally compiled java code because B can't override f() in A with weaker access privileges. But maybe it will appear in maliciously/purposefully made bytecode.
> As a conclusion, there is no problem in general cases, but there is a mistake semantically, IMHO.
> Regards
> -Weilei
> 
> 
> 
>