[Bug java/19738] gcjh generates invalid class member floating-point initialisers

rmathew at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Tue Feb 1 13:01:00 GMT 2005


------- Additional Comments From rmathew at gcc dot gnu dot org  2005-02-01 13:01 -------
(In reply to comment #2)
> Yes. Notice that also this code:
> 
> struct A
> {
>   static const int a = 45;
> };
> 
> is invalid without a matching definition. That is, you need to 
> provide a single definition of:
> 
> const int A::a;

Thanks, I understand this.

I was wondering why gcjh generates an explicit
(and incorrect for reals, as it turns out) initialisation
for a "final" Java field but not otherwise. That
is, given:

  static final int foo = 32;

  v/s

  static int bar = 42;

gcjh generates the initialiser only for "foo",
but not "bar".

In both cases, *someone* needs to initialise
these fields, right? Since these are generated
from Java classes, presumably the "Java side"
will initialise them - but then, why explicitly
write it out for "final" (const) fields?

This is what I attempted to suppress with my
patch in the first followup comment in this PR.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19738



More information about the Gcc-bugs mailing list