-Wmissing-field-initializers false positive with compound literals

-Wmissing-field-initializers false positive with compound literals

[Alexey Neyman]

Hi all,

I've encountered a weird behavior of -Wmissing-field-initializers option 
(which is a part of -Wextra) regarding structure initializers that 
contain compound literals as initializers for some of their fields. 
Reproduced with all GCC versions from 4.8.5 to 11.2.

Consider the following test case:

struct foo {
        const char *a1;
        const char * const *a2;
        void *a3;
        void *a4;
};

const char *aux[] = { "y", 0 };

struct foo a = {
        .a1 = "x",
#if defined(CASE1)
        .a2 = (const char * const []){ "y", 0 },
#elif defined(CASE2)
        .a2 = aux,
#elif defined(CASE3)
        .a2 = 0,
#elif defined(CASE4)
        /* .a2 not initialized */
#elif defined(CASE5)
        .a2 = (const char * const []){ "y", 0 },
        .a3 = 0,
#endif
};

struct foo b = {
        .a2 = (const char * const []){ "y", 0 },
        .a1 = "x",
};

CASE1 gives a warning about 'a3' field being initialized, despite the 
manual stating that named field initializers should prevent this warning 
from being generated. CASE2 initializes the field to point to an 
explicitly defined array, and it works with no warnings. CASE3 uses a 
constant as an initializer and also works without warnings. CASE5 
initializes the field 'a3' and produces no warnings about the next 
field, 'a4'.

Reversing the order of the 'a1' and 'a2' initializers (as in the 'b' 
variable) also does not produce a warning. It seems that the warning is 
only produced if the last initialized field in a structure uses a 
compound literal.

Looks like a bug to me; please confirm that I should file it into GCC's 
bugzilla.

Regards,
Alexey.

Re: -Wmissing-field-initializers false positive with compound literals

[Richard Sandiford]

Alexey Neyman <stilor@att.net> writes:
> Hi all,
>
> I've encountered a weird behavior of -Wmissing-field-initializers option 
> (which is a part of -Wextra) regarding structure initializers that 
> contain compound literals as initializers for some of their fields. 
> Reproduced with all GCC versions from 4.8.5 to 11.2.
>
> Consider the following test case:
>
> struct foo {
>         const char *a1;
>         const char * const *a2;
>         void *a3;
>         void *a4;
> };
>
> const char *aux[] = { "y", 0 };
>
> struct foo a = {
>         .a1 = "x",
> #if defined(CASE1)
>         .a2 = (const char * const []){ "y", 0 },
> #elif defined(CASE2)
>         .a2 = aux,
> #elif defined(CASE3)
>         .a2 = 0,
> #elif defined(CASE4)
>         /* .a2 not initialized */
> #elif defined(CASE5)
>         .a2 = (const char * const []){ "y", 0 },
>         .a3 = 0,
> #endif
> };
>
> struct foo b = {
>         .a2 = (const char * const []){ "y", 0 },
>         .a1 = "x",
> };
>
> CASE1 gives a warning about 'a3' field being initialized, despite the 
> manual stating that named field initializers should prevent this warning 
> from being generated. CASE2 initializes the field to point to an 
> explicitly defined array, and it works with no warnings. CASE3 uses a 
> constant as an initializer and also works without warnings. CASE5 
> initializes the field 'a3' and produces no warnings about the next 
> field, 'a4'.
>
> Reversing the order of the 'a1' and 'a2' initializers (as in the 'b' 
> variable) also does not produce a warning. It seems that the warning is 
> only produced if the last initialized field in a structure uses a 
> compound literal.
>
> Looks like a bug to me; please confirm that I should file it into GCC's 
> bugzilla.

Yeah, I agree it's a bug.  I think it's likely to be the same underlying
issue as PR82283, so I've copied the example there (hope you don't mind).

Thanks,
Richard