https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #31 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #29) > > however, I think that both the new attribute and the new C syntax extension > > should support the similar user interface. We might need to decide on this > > first. > > I think there are some fundamental differences: In one > case the size is encoded into the type and in the other > it is just an annotation that can be ignored. Yes, understood. I might not make myself clear in the previous message. what I mean by the "the similar user interfaces" is: both might support the following: 1. a declared variable as the size: **C syntax extension: unsigned int length; struct object { int others; char flex[length]; } **corresponding attribute: unsigned int length; struct object { int others; char flex[] __attribute__((__element_count__(length))); } 2. a declared field of the same structure as the size: **C syntax extension: struct object { unsigned int length; char flex[.length]; } **corresponding attribute: struct object { unsigned int length; char flex[] __attribute__((__element_count__(.length))); } 3. expressions including declared variables and declared fields of the same structure as the size: **C syntax extension: unsigned int item; struct object { unsigned int ratio; char flex[item * .ratio]; } **corresponding attribute: unsigned int item; struct object { unsigned int ratio; char flex[] __attribute__((__element_count__(item * .ratio))); } Not sure on the following case: 4. a declared field of the containing structure as the size: **C syntax extension: struct object { unsigned int length; struct inner { ... int flex[..length]; }; } **corresponding attribute: struct object { unsigned int length; struct inner { ... char flex[] __attribute__((__element_count__(..length))); } } what else from the user's point of view? > > > > > right now, the user interface we cannot agreed on is: > > > > whether we should support the following nested annotation (either with > > attribute or with the C syntax extension): > > > > struct object { > > ... > > unsigned int items; > > ... > > struct inner { > > ... > > int flex[]; > > }; > > } *ptr; > > > I am fine with supporting it, but one needs to decide > on the semantics in the case where inner is not accessed > via the outer struct. Yes, that's right.