[PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

[Martin Sebor]

On 01/17/2017 12:38 AM, Jakub Jelinek wrote:
> On Mon, Jan 16, 2017 at 05:06:40PM -0700, Martin Sebor wrote:
>> The test case submitted in bug 79095 - [7 regression] spurious
>> stringop-overflow warning shows that GCC optimizes some loops
>> into calls to memset with size arguments in excess of the object
>> size limit.  Since such calls will unavoidably lead to a buffer
>> overflow and memory corruption the attached patch detects them
>> and replaces them with a trap.  That both prevents the buffer
>> overflow and eliminates the warning.
>
> I fear this is going to break various 32-bit database programs and similar
> that mmap say 3GB of RAM and then work on that memory chunk as contiguous.
> Some things don't work too well in that case (pointer differences), but it
> is unlikely they would be using those, while your patch actively breaks it
> even for loops that can be transformed into memset (memcpy of course isn't a
> problem, because you need some virtual address space to copy it from).

I agree that breaking those applications would be bad.  It could
be dealt with by adding an option to let them disable the insertion
of the trap.  With the warning, programmers would get a heads up
that their (already dubious) code won't work otherwise.  I don't
think it's a necessary or wise to have the default mode be the most
permissive (and most dangerous) and expect users to tweak options
to make it safe.  Rather, I would argue that it should be the other
way around.  Make the default safe and strict and let the advanced
users who know how deal with the risks tweak those options.

Martin