forwarded message from owner-soot-list@sable.mcgill.ca

[John Plond JORGENSEN <jjorge1@cs.mcgill.ca>]

Approved: fjesiafeij
>From sysadmin@sable.mcgill.ca  Thu Sep 27 11:23:51 2001
Received: from ccn.CS.McGill.CA (ccn.CS.McGill.CA [132.206.3.87])
	by gloom.cs.mcgill.ca (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA27251
	for <soot-list@sable.mcgill.ca>; Thu, 27 Sep 2001 11:23:51 -0400
Received: from uqam.ca (anis.telecom.uqam.ca [132.208.250.6])
	by ccn.CS.McGill.CA (8.9.3/8.9.3) with ESMTP id LAA31784
	for <soot-list@sable.mcgill.ca>; Thu, 27 Sep 2001 11:23:50 -0400 (EDT)
	(envelope-from etienne.gagnon@uqam.ca)
Received: from er.uqam.ca (nobel.si.uqam.ca [132.208.219.1])
	by uqam.ca (8.11.6/8.11.0) with ESMTP id f8RFJsF17133;
	Thu, 27 Sep 2001 11:19:54 -0400 (EDT)
Received: from perseval (perseval.info.uqam.ca [132.208.137.96])
	by er.uqam.ca (8.10.0/8.10.0) with ESMTP id f8RFJtp16901;
	Thu, 27 Sep 2001 11:19:55 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=uqam.ca)
	by perseval with esmtp (Exim 3.32 #1 (Debian))
	id 15mcx8-0007ft-00; Thu, 27 Sep 2001 11:19:54 -0400
Message-ID: <3BB34399.7050708@uqam.ca>
Date: Thu, 27 Sep 2001 11:19:53 -0400
From: "Etienne M. Gagnon" <etienne.gagnon@uqam.ca>
Reply-To: soot-list@sable.mcgill.ca
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.4) Gecko/20010920
X-Accept-Language: en-us
MIME-Version: 1.0
To: soot-list@sable.mcgill.ca
CC: "Morozova, Anastasia" <amorozova@excelsior-usa.com>, vijaysun@ca.ibm.com
Subject: Re: OOPSLA'00 paper
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On Fri, 21 Sep 2001 20:33:51 +0700, Morozova, Anastasia wrote:
 >Dear Mr Gagnon,
 >
 >  It was very interesting for me to read the article "Practical Virtual Call
 >Resolution for Java"
 >  but I' ve got a problem considering the following example:
 >
 > class C{
 >  int m(){
 >    String[] a = new String[5];
 >    return a.hashCode();
 >  }
 > }
 >
 > After initialization, the "ReachingTypes" set of the representative node
 >"C.m.a" for the
 > array "a"  will be {nString}. No other types are propagated to it, so the
 >method call
 > a.hashCode() will be resolved to String.hashCode() while indeed the
 > Object.hashCode()
 > should be called.

Anastasia,

The type that will be propagated is "String[]" (array of String, 1 dimension), 
not "String".  So, a.hashCode() will finally resolve to a "hascode()" invocation 
on an instance of "String[]", and will thus have the right semantics (please 
correct me Vijay, if I am wrong).

The VTA analysis handles the following assignments differently:

1) a = b[3];
2) a[2] = b[y];
3) a = b;
4) a[x] = b;

The paper says that (3) has special handling if a or b has a "declared" Array or 
Object type.  In fact, this also includes declared types of Cloneable and 
Serializable (you should have guessed it).  If you still think there's a 
problem, it would be nice if you provided an example program (.java and .class), 
that gives wrong results after processing trhough Soot's VTA implementation.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/