[Soot-list] A minor difference of the example in "A survivor's Guide to Java Program Analysis with Soot"

[Eric Bodden]

Hi.

Thanks to Ben Bellamy and Oege de Moor, Soot 2.3.0 shipped with a new
type assigner for local variables (see CHANGELOG). From what I
understood at the time, this new assigner can indeed give you more
narrow types than the previous assigner that was in Soot. In the
example, the values of a and b do fit into a byte and so the new type
assigner just narrows down the type accordingly.

By the way I believe that this should only happen when you create
Jimple or Grimp from bytecode, not from source, because when going
from source then there's no need to infer types.

Eric

2009/9/3 jnuzhjp <jnuzhjp at 163.com>:
> Hi, Soot people. I got touched with Soot framework a week ago, so I  started
> with the Survivor's Guide of which the version is 1.1. The framework version
> I downloaded was the latest which was soot-2.3.0.When I came to chapter
> 3.4 Grimp and tried the Foo example, I found some minor differenece in the
> outputs after typing the command java soot.Main -f G Foo between  that of
> the tutorial and that of my practice. Here it comes:
> Source code:
> public class Foo
> {
>
> public static void main(String[] args)
> {
>
> Foo f = new Foo();
> int a = 7;
> int b = 14;
> int x = (f.bar(21) + a) * b;
>
> }
> public int bar(int n) {
> return n + 42;
> }
>
> }
> Grimp output in tutorial 1.1:
>        public static void main(java.lang.String[]) {
>
> java.lang.String[] r0;
> Foo r2;
> int i0, i1, i2;
> ..............................ellipse...............................
> Grimp output from my practice using soot-2.3.0:
> public static void main(java.lang.String[])
>     {
>         java.lang.String[] r0;
>         Foo r2;
>         byte b0, b1;
>         int i2;
>
>
> ................................ellipse................................
>
>     We can note that the type of  a and b in source code is different from
> that of the output resulted from practice using soot-2.3.0, the former is
> int but the latter has changed into byte.
>     I don' the know why the int type in this example has narrowed into byte
> type after transformation, is this one of the strategies of code
> optimization, would there be any collateral consequences?
> It'll be really appreciated for any answers. Thank you.
>
> Superloafer
> 2009-09-03
> ________________________________
> superloafer
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>



-- 
Eric Bodden
Software Technology Group, Technische Universität Darmstadt, Germany
Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt