> On Feb 8, 2023, at 2:09 PM, Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> But I noticed that “flexible_array_type_p” later was moved from FE to
>> middle-end and put into tree.cc, tree.h as a general utility routine, and to
>>
>> /* Determine whether TYPE is a structure with a flexible array member,
>> or a union containing such a structure (possibly recursively). */
>>
>> However, since this routine does not cover the cases when the structure
>> with flexible array member was recursively embedded into structures, (which
>> we
>> agreed that it should be considered as a flexible sized type).
>>
>> Therefore, I feel that It might not be proper to include this routine in
>> middle end
>> (and actually no other places In middle end use this routine so far).
>
> I think we've established that diagnostics and at least some middle-end
> purposes need different conditions.
Yes, agreed.
> Diagnostics for nesting a structure
> with a flexible array member inside another structure should only count []
> as a flexible array member,
Diagnostics should be consistent with the documentation.
The use cases that violate what is defined in documentation should be
diagnostics.
This include both C standard and GCC extension.
For C standard violation, -pedantic will report them.
For GCC extension, the corresponding warning message should report them.
And both such warning can be issued either in FE or in Middle end.
Is the above understand correct?
> whereas permitting flexible array uses in the
> middle end should allow [0] and [1] under some circumstances (depending on
> command-line options).
>
>> But:
>>
>> struct flex0 { int n; int data[0]; };
>> struct out_flex_end0 { int m; struct flex0 flex_data; };
>> struct outer_flex_end0 { int p; struct out_flex_end0 out_flex_data; };
>>
>> In the above, only “flex0” is flexible sized type by default.
>> But “out_flex_end0” and “out_flex_end0” are Not considered as flexible sized
>> type by default?
>
> It would be OK (and I'm not saying here that this is necessarily
> desirable), since that's at the end of another structure rather than in
> the middle, to consider them flexible for the purposes of code generation.
This is the part I am still not very clear and not feel very comfortable:
In the documentation on GCC extension of embedding structure with flexible
array member into another structure/union,
Should we include [0], [1] and [n] cases as GCC extension by default? Or we
only include [] for nested struct as an extension?
For example:
struct flex0 { int length; char data[0]; };
struct out_flex0 { int m; struct flex0 flex_data; };
struct out_flex0_mid { struct flex0 flex_data; int m};
Should we treat the above out_flex0->flex_data as flexible array by default?
Should we issue warning for the above out_flex9_mid with a new warning option
-Wgnu-variable-sized-type-at-end?
How about the following:
struct flex1 { int length; char data[1]; };
struct out_flex1 { int m; struct flex1 flex_data; };
struct out_flex1_mid { struct flex1 flex_data; int m};
And:
struct flexn { int length; char data[4]; };
struct out_flexn { int m; struct flexn flex_data; };
struct out_flexn_mid { struct flexn flex_data; int m};
????
>
> What must be avoided is -pedantic diagnostics for
>
> struct flex1 { int n; int data[1]; };
> struct out_flex_end1 { int m; struct flex1 flex_data; };
>
> regardless of whether considered flexible or not, since that's clearly
> valid in standard C.
Yes, agreed.
Thanks.
Qing
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
