Re: [Fwd: Solution?]

[Raja Vallee-Rai <kor@sable.mcgill.ca>]

>>  > return value is converted to a short. The java language spec states
>  > (5.1.3)
>  > that narrowing of basic types is not type safe.
>  >
>  >     For example, in one case the returned value is 45???, which
>  > converted to short gives -2???? (? means I dont remember the exact
>  > value).
>  >
>  >     There must be an underlying bug in the classfile reading logic, I
>  > would be amazed that a class would have 45000 attributes.
>  >
>  >     I have not invested too many time in this, maybe there is a
> simple
>  > solution or even that this is but a effect of another cause...
>  >
>  >     Any info welcome!
> 
>  Hmmm, well I tried jimplifying java.lang.String using jdk1.1.3 on a
>  Sparc, and it worked fine.  Did you try getting the .tar.gz files and
>  running on those to see if maybe you have corrupted classfiles?
> 
>  Otherwise maybe you could just print out the values that the various
>  readUnsignedShort() returns to see if it matches the classfiles
>  contents.
> 
>  This is very bizarre.  Does anybody have a clue as to what might be
> happening here?
> 

Actually what might be happening is that it is loading a classfile with
45,000 attributes which happens to have less on my system.  Can you try:

java ca.mcgill.sable.soot.jimple.Main -verbose java.lang.string

This will say what file it's trying to resolve before it chokes and
throws an exception.    Although you are right, it should have (int)'s
instead of (short)'s as it will retrieve wrong values if you actually
have a big classfile.

I'll fix this for 1.beta.2.  This second version will also have
deterministic jimplification. :)



Raja