[PING #3][PATCH] separate reading past the end from -Wstringop-overflow

[Martin Sebor]

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html

On 7/13/20 6:05 PM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
> 
> On 7/7/20 12:56 PM, Martin Sebor wrote:
>> Ping.  Despite its size, there isn't much new in the patch, it
>> pretty much just splits an existing warning into two, one for
>> buffer overflow and another for "overread."
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
>>
>> On 6/23/20 8:05 PM, Martin Sebor wrote:
>>> -Wstringop-overflow is issued for both writing and reading past
>>> the end, even though the latter problem is often viewed as being
>>> lower severity than the former, or at least sufficiently different
>>> to triage separately.  In CWE, for example, each of the two kinds
>>> of problems has its own classification (CWE-787: Out-of-bounds
>>> Write, and CWE-125: Out-of-bounds Read).
>>>
>>> To make this easier with GCC, the attached patch introduces
>>> a new option called -Wstringop-overread and splits the current
>>> indiscriminate warning into the respective two categories.  Other
>>> than the new option the improvements also exposed a few instances
>>> of reading past the end that GCC doesn't detect that the new code
>>> does thanks to more consistent checking.
>>>
>>> As usual, I tested the patch by building Binutils/GDB, Glibc, and
>>> the Linux kernel with no unexpected (or any, in fact) instances
>>> of the two warnings.
>>>
>>> The work involved more churn that I expected, and maintaining
>>> the expected precedence of warnings (missing terminating nul,
>>> excessive bounds, etc.) turned out to be more delicate and time
>>> consuming than I would have liked.  I think the result is cleaner
>>> code, but I'm quite sure it can still stand to be made better.
>>> That's also my plan for the next step when I'd like to move this
>>> checking out of builtins.c and calls.c and into a file of its own.
>>> Ultimately, Jeff and have would like to integrate it into the path
>>> isolation pass.
>>>
>>> Martin
>>>
>>> PS There's a FIXME comment in expand_builtin_memory_chk as
>>> a reminder of a future change.  It currently has no bearing
>>> on anything.
>>
>