On 03/19/2011 09:57 PM, Soeren Sandmann wrote:> Consider this fragment of Java code:>> int i, j;>> i = 100;> for (i>= 0&& (j = 10) == 10)> i = j;>> This is correct; j is not used without being initialized, and the Java> compiler accepts it without complaints.

It is correct if you s/for/if/; I am going to assume that this is what
you meant. The equivalent code that I have is the following (many thanks
to javap -c):

> This code can obviously be improved, and some fairly trivial> optimizations will slim down the control flow graph enough to make it> understandable to the verifier. However, it bugs me that I have to rely> on optimizations in order to get working code, because, among other> things, there is no way to be sure that it's sufficient in all cases.

If you look at the difference between javac and your code generator, you
will notice that the generation of short-circuit and is different. javac
essentially compiles it as

> Is there a standard way to get around this problem? Ie., a systematic> way to ensure that the code generated will not only be correct, but also> verifiable?

I suppose the problem is in the generation of short-circuit operators.
If you branch to the 'else' target as soon as you fail a condition, you
essentially make the code identical to the nested case, which will be
correctly verifiable, since you can definitely ascertain that all of the
conditions have been hit in the body of the if statement. I wouldn't
call this an optimization, insomuch as a short-circuit and operator can
be called mere syntactic sugar for doing potentially highly-nested
condition statements.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth