On Fri, May 05, 2017 at 08:50:04AM -0700, Andi Kleen wrote:
> Richard Sandiford <richard.sandif...@linaro.org> writes:
>
> > tree-ssa-strlen.c looks for cases in which a string is built up using
> > operations like:
> >
> > memcpy (a, "foo", 4);
> > memcpy (a + 3, "bar", 4);
> > int x = strlen (a);
> >
> > As a side-effect, it optimises the non-final memcpys so that they don't
> > include the nul terminator.
> >
> > However, after removing some "& ~0x1"s from tree-ssa-dse.c, the DSE pass
> > does this optimisation itself (because it can tell that later memcpys
> > overwrite the terminators). The strlen pass wasn't able to handle these
> > pre-optimised calls in the same way as the unoptimised ones.
> >
> > This patch adds support for tracking unterminated strings.
>
> Would that be useful as a warning too? If the pass can figure out
> the final string can be not null terminated when passed somewhere else,
> warn, because it's likely a bug in the program.
Why would it be a bug? Not all sequences of chars are zero terminated
strings, it can be arbitrary memory and have size somewhere on the side.
Also, the fact that strlen pass sees a memcpy (a, "foo", 3); and a passed
somewhere else doesn't mean a isn't zero terminated, the pass records only
what it can prove, so even when you have:
memcpy (a, "abcdefgh", 9);
*p = 0; // unrelated pointer, but compiler can't prove that
memcpy (a, "foo", 3);
call (a);
there is really nothing wrong with it, the string is still zero terminated.
The pass had to flush the knowledge that it knew length of a on the wild
pointer store.
Jakub
