Re: [patch] Java definite assignment

[Mo DeJong <mdejong at cygnus dot com>]

On 6 Feb 2001, Per Bothner wrote:

> Mo DeJong <mdejong@cygnus.com> writes:
> 
> > Well, here is a much more simple case of the same thing,
> 
> No, it is very different, because there is no loop.

...

> The point is in:
> 
>         for (;;) {
>            if (b) {
>                 i = 0;
>                 break;
>             }
>         }
> 
> the only way the loop can terminate is by executing the break
> statement, and i *is* definitely assigned at that point.  Hence i is
> definitely assigned after the loop.  However, i is *not* definitely
> assigned after the 'if' statement, were there another statement there.

After reading up on the rules in 16.2.9, I now think
that you are correct for the cases where the
if statement is true or is not a compile time
constant.

I am still not sure about this case:

        int i;
        while (true) {
            if (false) {
	        i = 0;
                break;
            }
        }
        i++;

It fails the definite assignment
analysis for 16.2.7, but it
satisfies the rules for 16.2.9.

Chapter 16 indicates that the
following 4 results of the
definite assignment analysis
are possible.

1. V is definitely assigned and is not definitely
unassigned. (The flow analysis rules prove that
an assignment to V has occurred.)

2. V is definitely unassigned and is not definitely
assigned.(The flow analysis rules prove that an
assignment to V has not occurred.) 

3. V is not definitely assigned and is not
definitely unassigned.(The rules cannot prove
whether or not an assignment to V has occurred.)

4. V is definitely assigned and is definitely
unassigned.(It is impossible for the statement
or expression to complete normally.)

I think in this case, we have hit #4,
it is both definitely assigned and
definitely unassigned (fun). Do
we need to treat this as
an unreachable statement? For
example, javac pukes on
the following:

        int i;
        while (true) {}
        i++;

tmp7.java:7: unreachable statement
        i++;
        ^
1 error

Is doing this definite assignment
analysis the only way we can
determine if the loop cannot exit?

Mo DeJong
Red Hat Inc