[Patch] Java: Definite [Un]Assignment Issues

Per Bothner per@bothner.com
Fri May 28 03:35:00 GMT 2004


Ranjit Mathew wrote:
> 
>     final int i;
>     i = 1;
>     if (false)
>       i = 2;
> 
> versus:
> 
>     final int i = 1;
>     if (false)
>       i = 2;
> 
> The former is not an error, but the latter is.

This is another of those "sadistic test case" that I don't think are
very important, but as you've already implemented a fix, and it appears
simple, we might as well follow Sun.

> (Recall that after a boolean
> constant expression with value false "when true", a variable is
> *both* definitely assigned as well as definitely unassigned - a
> blank final variable can only be assigned to when it is definitely
> unassigned, while an initialised final variable cannot be assigned
> to at all.)

I think you're right.

>>I'll get back to you on the check_bool_init patch.

It looks OK, but after looking the spec, I wonder whether
following is also correct and simpler (more robust):

     case MODIFY_EXPR:
       check_init (exp, before);
       COPY (when_true, before);
       COPY (when_false, before);
       break;
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/



More information about the Gcc-patches mailing list