On 01/17/2017 08:16 PM, Martin Sebor wrote:
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.
I still come back to the assertion that changing this loop to a mem* is
fundamentally the wrong thing to do as it changes something that has
well defined semantics to something that is invalid.
Thus the transformation into a mem* call is invalid.
jeff
