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. So we're in stage1, so you're good to go with the patch as-is or revamped per the discussion above.
jeff >
