Re: [PATCH] Fix PR 86572

[Martin Sebor <msebor at gmail dot com>]

On 10/22/2018 09:08 AM, Bernd Edlinger wrote:
> Hi!
>
> This makes c_strlen avoid an unsafe strlen folding of const arguments
> with non-const offset.  Currently a negative out of bounds offset
> makes the strlen function return an extremely large number, and
> at the same time, prevents the VRP machinery, to determine the correct
> range if the strlen function in this case.
>
> Fixed by doing the whole computation in size_t and casting the
> result back to ssize_t.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

In general, I view folding to a "safe" value as done in this patch
(and as Richard suggests in his comment on the bug) far preferable
-- as in far safer/more secure -- to avoiding folding in these
cases (currently the prevailing strategy).

If there is consensus on adopting this approach for strlen I'd like
to see it applied in other such cases as well as a matter of policy.

Some other similar examples to consider include:

 *  calling other built-ins on such arrays, including strnlen,
    memchr/strchr, and strpbrk
 *  indexing into such an array (note that accesses at constant
    out-of-bounds indices into constant arrays are already folded
    to zero, although that may be an accidental rather than
    a conscious decision made to avoid the worst kind of fallout).

None of these is currently folded to a safe value.  GCC calls
the library functions for the built-ins in the first bullet when
the argument is a constant string with a non-constant offset,
even though it could fold them.

At some point it would be also helpful to try to get consensus
on whether emitting a trap in these cases (perhaps under
an option) is something to start moving toward, as we discussed
at Cauldron.

Martin