> On Feb 7, 2023, at 6:37 PM, Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> 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?
>
> My comments were about basic principles of what gets diagnosed, and the
> need for different predicates in different contexts; I wasn't trying to
> assert anything about how that maps onto what functions should be used in
> what contexts.
Okay.
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).
That’s the reason I asked the previous question.
It might be better to move the routine “flexible_array_type_p” back from
middle-end to
FE for the diagnosis purpose only.
>
>>>> 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 [].
>
> There are different sorts of diagnostic that might be involved.
>
> * Simply having [0] or [1] at the end of a structure embedded in another
> structure isn't appropriate to diagnose, because [0] and [1] have
> perfectly good meanings in such a context that aren't trying to be
> flexible array members at all. [0] might be an empty type (possibly one
> that wouldn't be empty when built with a different configuration). [1]
> might be the use of arrays in C to produce a passed-by-reference type.
So, you mean, by default, Only having [] at the end of a structure embedded
in another structure is considered to be flexible sized type?
i.e.
struct flex { int n; int data[ ]; };
struct out_flex_end { int m; struct flex0 flex_data; };
struct outer_flex_end{ int p; struct out_flex_end0 out_flex_data; };
In the above, all “flex”, “out_flex_end” and “outer_flex_end” are flexible
sized type.
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?
>
> * Trying to use such an embedded [0] or [1] array as if it were a flexible
> array member - i.e. accessing any member of the [0] array, or any member
> other than the [0] member of the [1] array - *is* a sign of the
> problematic use as a flexible array member, that might be appropriate to
> diagnose.
Yes, this was diagnosed with -Wstrict-flex-arrays + -fstrict-flex-arrays=n.
thanks.
Qing
> (Actually I'd guess the array index tends to be non-constant in
> accesses, and it would be odd to use a non-constant index when you mean
> that constant always to be 0, which it would need to be in the
> non-flexible case.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
