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.  Diagnostics for nesting a structure 
with a flexible array member inside another structure should only count [] 
as a flexible array member, 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.

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.

-- 
Joseph S. Myers
joseph@codesourcery.com