https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117516
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Same just using the preprocessor:
struct S10 { int a, b; };
#define A(m, n) struct S##m { struct S##n a, b; };
#define B(m) A(m##1, m##0) A(m##2, m##1) A(m##3, m##2) A(m##4, m##3) \
A(m##5, m##4) A(m##6, m##5) A(m##7, m##6) A(m##8, m##7)
B(1)
#define S20 S18
B(2)
#define S30 S28
B(3)
int
main ()
{
struct S38 s;
__builtin_memset (&s, 0, sizeof (s));
}
I must say I don't really understand the recursion.
If we have say
struct A { int a; char b[]; int c; };
struct B { struct A a; struct A b[]; struct A c; };
struct C { struct B a; struct B b[]; struct B c; };
C c;
then we want to diagnose just 3 errors, the flex array in the middle of each
struct.
But that can be done when completing each of the structs. I can understand
recursion for the checks whether the last FIELD_DECL has a type which ends with
a flex array, but I don't see why it should recurse on other FIELD_DECLs for
more than one level (so
say when finalizing C, check whether B ends with a flex array (for a field's
purposes),
see the problem with the b[] flex array and be ok with flex array at the end of
B for field c because nothing follows that.
