This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Java: Definite [Un]Assignment Issues
- From: Per Bothner <per at bothner dot com>
- To: Ranjit Mathew <rmathew at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Thu, 27 May 2004 16:24:45 -0700
- Subject: Re: [Patch] Java: Definite [Un]Assignment Issues
- References: <email@example.com> <40B16AFF.firstname.lastname@example.org> <email@example.com>
Ranjit Mathew wrote:
final int i;
i = 1;
i = 2;
final int i = 1;
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):
check_init (exp, before);
COPY (when_true, before);
COPY (when_false, before);