[Bug tree-optimization/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

["qinzhao at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832

--- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to Jakub Jelinek from comment #3)
> > This is intentional, if you embed an aggregate with flex array into another
> > struct and ask not to cross the field boundaries (i.e. bos1), then the size
> > of that field is exactly what is the maximum size.
> 
> As we discussed in PR 107952
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952):
> 
> GCC extension accepts the following two cases:
> 
> **Case 1:
> 
> struct A { char data[1]; };
> struct B { int n; struct A a; };
> 
> as if the a.data[] array is a flex-array.  
> 
> **Case 2: 
> 
> struct C { int n; struct A a; int x; };
> 
> as if a.data[] can be up to 4 elements. 
> 
> So, what's you mean by "not to cross the field boundaries" is for the above
> Case 2? 
> For Case 1, we should treat A.data as flexible array, and then B.A as a
> structure that has flexible array, therefore B.A's size is flexible too. 
> 
> Is my understanding correct?


After discussion, the following patch to clarify the above two cases was
approved:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620122.html

with this clarification, the above case 1 is accepted as a GCC extension, but
case 2 will be deprecated. a warning option -Wflex-array-member-not-at-end is
provided to detect case 2 in the user code. 

please see also PR77650.