Re: [PATCH] Make strlen range computations more conservative

[Martin Sebor <msebor at gmail dot com>]

On 08/02/2018 12:20 PM, Jakub Jelinek wrote:
> On Thu, Aug 02, 2018 at 11:00:32AM -0600, Martin Sebor wrote:
> > As an alternate approach I have been thinking about, if
> > there is a strong feeling that allowing strlen to iterate
> > past the subobject boundary is necessary (I don't believe
> > it is.)
> >
> > Rather than indiscriminately expanding the provenance of
> > the subobject regardless of what members follow it in
> > the enclosing structure, only consider doing that if
> > the next member is an array of the same type.  E.g.,
> >
> >   struct S { char a[4], b[3], c[2], d; };
> >   extern struct S *p;
> >
> >   strlen (p->a);   // consider p->a's bounds to be char[9]
>
> See the mail with testcases where the middle-end doesn't distinguish
> between p->a and (char *) p, unless you want to warn or optimize
> in the FEs or extremely early in the lowering passes, that isn't going to
> work.

When the object structure is lost (as in MEM_REF) the middle-end
(specifically strlen) already considers the whole object, so that
wouldn't change.  The only impact would be on the cases where
the middle end currently does consider the subobject: instead
of taking just its size, it would consider the size of
the subsequnt members.  For the case of strlen, that would be
a simple change to get_range_strlen().

Martin