Re: How to deal with implicit call in Spark?

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

I tried your example with the development version of Soot. In the
points-to set for "in", I get, among a few other things:

AllocNode 2166 new java.net.SocketInputStream in method <java.net.PlainSocketImpl: java.io.InputStream getInputStream()>

The call to in.read comes up with exactly one target:

CallGraph: Type: VIRTUAL Target Method: <java.net.SocketInputStream: int read(byte[])>

Ondrej

On Wed, May 21, 2003 at 05:38:26PM -0400, CHEN FU wrote:
> Thanks for the direction and
> leastObject should mean any object here, right?
> 
> But consider the main method below:
> 
>     Socket socket = new Socket("127.0.0.1", 56);
>     InputStream in = socket.getInputStream();
> 
>     byte[] buf = new byte[20];
>     int i = in.read(buf);
>     System.out.println(buf.toString());
> 
> and consider the call site in.read(buf). It looks very strange to me that:
> after using spark to trim the call graph, this call site has no target
> left. So it seems to me the points to set of the reference "in" is not
> correct due to the native methods.
> 
> 
> On Wed, 21 May 2003, Feng QIAN wrote:
> 
> > It is not a fault of the Spark. The side effect of native methods are
> > simulated in soot/jimple/toolkits/pointer/nativemethods, for example,
> > AccessController.doPrivileged is simulated in
> > JavaSecurityAccessControllerNative.java. The return variable of
> > doPrivileged is assigned a least object:
> > NativeHelper.assignObjectTo(returnVar, Environment.v().getLeastObject());
> > 
> > I am not sure if this addresses your concern?
> > 
> > Cheers,
> > -- Feng
>