> On Feb 7, 2023, at 2:17 PM, Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> 1. Structure with flexible array member embedded into other structures
>> recursively, for example:
>>
>> struct A {
>> int n;
>> char data[];
>> };
>>
>> struct B {
>> int m;
>> struct A a;
>> };
>>
>> struct C {
>> int q;
>> struct B b;
>> };
>>
>> In the above, “struct C” will not be caught by this routine.
>
> Because struct B is diagnosed with -pedantic when it embed struct A, there
> is no need for -pedantic to diagnose struct C as well when it embeds
> struct B.
Oh, yes.
Then, this routine (flexible_array_type_p) is mainly for diagnostic purpose.
It cannot be used to determine whether the structure/union type recursively
include a flexible array member at the end.
Is my understanding correct?
>
>> 2. Only C99 standard flexible array member be included, [0] and [1] are
>> not included, for example:
>
> Obviously we can't diagnose use of structures with [1] trailing members,
> because it's perfectly valid to embed those structures at any position
> inside other structures. And the same is the case for the [0] extension
> when it's used to mean "empty array" rather than "flexible array".
With the -fstrict-flex-arrays available, we should be able to diagnose
the flexible array member per gnu extension (i.e [0] or [1]) the same as [].
>
> Note that my comments above are about what diagnostics are appropriate
> under the standard. They are *not* about how code generation might allow
> for possible uses of certain source code constructs as if they were
> flexible array members. The two contexts may very well require different
> notions of what counts as a flexible array member.
Yes. That’s right.
Thanks.
Qing
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
