Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Qing Zhao <qing.zhao@oracle.com>]

> On Feb 7, 2023, at 6:37 PM, Joseph Myers <joseph@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
> joseph@codesourcery.com