[PING #2][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/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.
>