[Soot-list] Soot typing issue: local gets the null_type

[Todd Wallentine]

Thanks for the information.  I guess I just didn't understand what the 
"null_type" is in Jimple.  It now makes more sense to me and it seems 
like I need to change the translation in some way to reflect these 
semantics (previously, we simply translated the null_type into 
java.lang.Object).

todd
ps
I know the input code is not too meaningful.  The problem was that it 
was failing the type-checking in Bogor and not failing model-checking.

Etienne Gagnon wrote:
> Hi Todd,
> 
> The type inference result, for local variable n0, is correct.  null_type
> is a subtype of all reference types.  A problem happens when you want to
> use this inferred type in a program, as it is a theoretical type.  But,
> just think about the following verifiable bytecode written is pseudo-java:
> 
> {
>   null_type n0;
> 
>   n0 = null;
> 
>   staticinvoke <Foo: void test1(String)>(n0);
>   staticinvoke <Foo: void test1(Number)>(n0);
> }
> 
> This code will be accepted by the verifier.  Yet, if you try giving n0
> any other static type, one of the two invokes will reject it.
> 
> So, if you really want to use it, simply replace null_type by Object,
> and add casts on every use, as in:
> 
> {
>   Object n0;
> 
>   n0 = null;
> 
>   staticinvoke <Foo: void test1(String)>((String) n0);
>   staticinvoke <Foo: void test1(Number)>((Number) n0);
> }
> 
> Of course, if you regenerate bytecode, you there is no problem as local
> variables have no declared type.  I designed the type inferer primarily
> for a bytecode optimization framework, so null_type wasn't a problem in
> such environment.  :-)
> 
> Have fun!
> 
> Etienne
> 
> Todd Wallentine wrote:
>>     public static void main(java.lang.String[])
>>     {
>>         java.lang.String[] r0;
>>         Foo $r1, r2;
>>         null_type n0;
>>
>>         r0 := @parameter0: java.lang.String[];
>>         $r1 = new Foo;
>>         specialinvoke $r1.<Foo: void <init>()>();
>>         r2 = $r1;
>>         n0 = null;
>>         virtualinvoke n0.<Foo: void inc()>();
>>         return;
>>     }
>>
>> To reiterate the question, is this a bug or my lack of understanding of
>> what the type system can/should provide?
>