Jimple Type Assign error

[John Jorgensen <jorgnsn@lcd.uregina.ca>]

>>>>> "olhotak" == Ondrej Lhotak <olhotak@sable.mcgill.ca> writes:

    olhotak> On Thu, Aug 12, 2004 at 07:57:54PM +0200, Jooyong Lee wrote:
    jlee> 
    jlee> I was making some soot translators, and all seemed to work
    jlee> well, but when I applied my translator to the following
    jlee> IfTest class file, all of a sudden I was trapped in a
    jlee> NullpointExceptionError thrown by TypeAssigner.  

    olhotak> Yes, this is a bug in the type assigner. It's the
    olhotak> same one that has been reported before.

It turns out to be the same bug as I kludged around a couple of
years ago.

Jennifer: 
I've checked in a change to the Soot repository which extends the
kludge, to handle the manifestation of the bug triggered by
your test case and by Jooyong's example.

Jooyong: 
I'll append a patch which you can apply to the
soot-2.1.0 release, in case you're using that instead of a copy
of the current source from the repository.

Etienne: 
I'd appreciate your advice on whether to extend this kludge more
widely yet...

As Ondrej wrote earlier, this NullPointerException occurs when
soot.jimple.toolkits.typing.integer.ConstraintChecker.caseIfStmt()
tries to create a cast to the type of the R0_127 TypeNode, which
has a type() of null.  

I ran into this a couple of years ago, when the type cast was
introduced by
soot.jimple.toolkits.typing.integer.ConstraintChecker.caseAssignStmt().
At that time you vetoed the idea of actually giving the R0_1,
R0_127, and R0_32767 TypeNodes non-null types, on the grounds
that it might mask other errors (and subsequently I noticed that
the existing code already includes tests against null values for
TypeNode.type(), so gratuituously giving all TypeNodes non-null
type values could indeed have bad consequences).

So I wrote a function, getTypeForCast(TypeNode t) which returns
t.type(), except in the case where t corresponds to R0_1, R0_127,
or R0_32767, in which case it returns BooleanType.v(),
ByteType.v(), or ShortType.v(), respectively.  Then in the call
to insertCast() which had triggered the NullPointerException, I
substituted getTypeForCast(t) for t.type().

(You can see the actual diff by pointing your browser at

  http://svn.sable.mcgill.ca/viewcvs/soot/trunk/src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java?r1=406&r2=531&p1=soot/trunk/src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java&p2=soot/trunk/src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java

or running

  svn diff -r 406:531 https://svn.sable.mcgill.ca/soot/soot/trunk/src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java
)

In response to the bugs reported by Jennifer and Jooyong, I made
the same substitution in another call to insertCast()
(introducing revision 1761, if you want to look at it in detail).  

Do you anticipate any problem with making the same subsitution in
all calls to insertCast() which pass the value of
soot.jimple.toolkits.typing.integer.TypeNode.type()?  I don't see
how it could cause a problem, other than the minute degradation
in performance.

--- src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java	2003-12-18 11:43:04.000000000 -0600
+++ /tmp/ConstraintChecker.java	2004-08-15 19:02:09.000000000 -0600
@@ -1076,12 +1076,12 @@
 	      {
 		if(!lop.hasAncestor_1(ClassHierarchy.v().INT))
 		  {
-		    expr.setOp1(insertCast(expr.getOp1(), lop.type(), rop.type(), stmt));
+		    expr.setOp1(insertCast(expr.getOp1(), getTypeForCast(lop), getTypeForCast(rop), stmt));
 		  }
 		
 		if(!rop.hasAncestor_1(ClassHierarchy.v().INT))
 		  {
-		    expr.setOp2(insertCast(expr.getOp2(), rop.type(), lop.type(), stmt));
+		    expr.setOp2(insertCast(expr.getOp2(), getTypeForCast(rop), getTypeForCast(lop), stmt));
 		  }
 	      }
 	    else