GCC bug ?

[Bruce Evans]

On Sat, 14 Feb 2004, Poul-Henning Kamp wrote:

> This seems wrong to me, GCC should warn about the double initialization.
>
> critter phk> cat a.c
>
> struct foo {
>         int bar;
>         int barf;
> };
>
> struct foo myfoo = {
>         .bar = 1,
>         .bar = 2,
> };
> critter phk> cc -Wall -c a.c
> critter phk>

This seems to be a feature.  From n869.txt:

%%%
       [#19]  The  initialization  shall  occur in initializer list
       order, each initializer provided for a particular  subobject
       overriding  any  previously  listed initializer for the same
       subobject;  all  subobjects   that   are   not   initialized
       explicitly  shall  be  initialized  implicitly  the  same as
       objects that have static storage duration.
%%%

Initialization of a previously inititialized subobject should be allowed
when the previous initialization was the default.  Perhaps it was too
hard to specify a non-overriding behaviour for later initializations in
special cases.  Yes, the following should work too:

%%%
struct foo {
	int	f_bar;
	int	f_barf;
};

struct foobar {
	struct foo fb_bar;
	int	fb_barf;
};

struct foobar myfoobar = {
	.fb_bar = { 1 },
	.fb_bar.f_barf = 2,
};
%%%

".fb_bar.f_barf" is initialized twice, first with the default part of an
expilicit initialization.  I could have avoided the first initialization
by initializing only .fb_bar.f_bar, but chose not to, to give an example.
More complicated examples might not have a choice in practice.  Also, the
opposite order might be needed:

struct foobar myfoobar = {
	.fb_bar.f_barf = 2,
	.fb_bar = { 1 },
};

to suit complexities not shown in this example.  The above just clobbers
the first initialization of ".fb_bar.f_barf".  In a more complicated
example, clobbering some initializations might be hard to avoid.  Then
further initializations would be needed to unclobber them.

Bruce