[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