This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java 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: <c8qerl$o55$1@sea.gmane.org> <40B16AFF.8020909@bothner.com> <c8s6n5$47r$1@sea.gmane.org>
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/