[PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

[Jeff Law]

On Thu, 2020-04-23 at 16:05 -0600, Martin Sebor wrote:
> On 4/23/20 9:42 AM, Jeff Law wrote:
> > On Wed, 2020-04-22 at 15:36 -0600, Martin Sebor via Gcc-patches wrote:
> > > When computing the size of an object with a flexible array member
> > > the object size pass doesn't consider that the initializer of such
> > > an object can result in its size being in excess of the size of
> > > the enclosing type.  As a result, stores into such objects by
> > > string functions causes false positive warnings and can abort
> > > at runtime.
> > > 
> > > The warnings are an old regression but as more of them make use
> > > of the object size results more of them are affected by the bug.
> > > The abort goes back to when support for _FORTIFY_SOURCE was added.
> > > 
> > > The same problem has already been independently fixed in GCC 10
> > > for -Warray-bounds which doesn't use the object size checking pass,
> > > but the object size bug still remains.  The attached patch corrects
> > > it as well.
> > > 
> > > Tested on x86_64-linux.
> > Do you need to change guarding condition to use decl_init_size instead of
> > DECL_SIZE_UNIT as well?
> > 
> >   else if (pt_var
> >             && DECL_P (pt_var)
> >             && tree_fits_uhwi_p (DECL_SIZE_UNIT (pt_var))
> >                                  ^^^^^^^^^^^^^^
> >             && tree_to_uhwi (DECL_SIZE_UNIT (pt_var)) < offset_limit)
> >                              ^^^^^^^^^^^^^^
> 
> It doesn't see that changing it is strictly necessary.  If the tests
> above pass and the result doesn't satisfy the conditions because it's
> either null or doesn't fit in UHWI it's handled later by returning
> false.  With offset_limit set to SIZE_MAX / 2, I don't think the result
> can as big as that or bigger: it would imply the whole object, including
> its initializer, is bigger than half the address space and GCC rejects
> such objects with an error.  I've added another test in the patch to
> to verify this.
> 
> I do agree it would be better to validate the final result the same
> way.  That makes the change a little more intrusive to avoid validating
> the size multiple times, but I think it also improves the readability
> of the code, so the updated patch does that.  It passes testing on
> x86_64-linux.
> 
> Let me know which one of the two you prefer, or if you'd rather hold
> off until stage 1.
I think at this point we should defer.  
jeff
>