On Thu, Sep 22, 2022 at 11:26:29AM -0400, Siddhesh Poyarekar wrote:
> On 2022-09-22 09:02, Jakub Jelinek wrote:
> > On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote:
> > > --- a/gcc/tree-object-size.cc
> > > +++ b/gcc/tree-object-size.cc
> > > @@ -495,6 +495,18 @@ decl_init_size (tree decl, bool min)
> > > return size;
> > > }
> > > +/* Get the outermost object that PTR may point into. */
> > > +
> > > +static tree
> > > +get_whole_object (const_tree ptr)
> > > +{
> > > + tree pt_var = TREE_OPERAND (ptr, 0);
> > > + while (handled_component_p (pt_var))
> > > + pt_var = TREE_OPERAND (pt_var, 0);
> > > +
> > > + return pt_var;
> > > +}
> >
> > Not sure why you want a new function for this.
> > This is essentially get_base_address (TREE_OPERAND (ptr, 0)).
>
> Oh, so can addr_object_size be simplified to use get_base_address too?
You can try. As you can see in get_base_address, that function
handles something that the above doesn't (looking through some MEM_REFs too).
> > Even if c_strlen (src, 1) is constant, I don't see what you can assume
> > for object size of strndup ("abcd\0efgh", n); for minimum, except 1.
>
> Can't we assume MIN(5, n) for STRING_CST?
If you mean MIN(5, n + 1), for c_strlen constant yes, but say if you have
strndup (&"abcd\0efgh"[i], n); you can't just from seeing a base address
being a STRING_CST with certain length assume anything than 1.
> For ARRAY_REFs, it may end up being MIN(array_size, n) and not account for
No, for non-OST_MINIMUM array size of objects (or string literals) containing
the strings is relevant and you can indeed use MIN(__b{d}os (src), n + 1)
as maximum. But for the minimum, the object size is irrelevant, you don't
know where in the string there are '\0's and they could appear anywhere
(unless you do string length range analysis). With c_strlen on src
returning constant you know the exact string length and so you can use
MIN (c_strlen (src, 1) + 1, n + 1) as both minimum and maximum, but in all
other cases, 1 is the safe answer.
Jakub
