This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] prevent -Wno-system-headers from suppressing -Wstringop-overflow (PR 79214)


On 01/25/2017 02:12 PM, Martin Sebor wrote:
While putting together examples for the GCC 7 changes document
I noticed that a few of the buffer overflow warnings issued by
-Wstringop-overflow are defeated by Glibc's macros for string
manipulation functions like strncat and strncpy.

While testing my fix I also noticed that I had missed a couple
of functions when implementing the warning: memmove and stpcpy.

The attached patch adds handlers for those and fixes the three
bugs below I raised for these omissions.

Is this patch okay for trunk?

PR preprocessor/79214 -  -Wno-system-header defeats strncat buffer
  overflow warnings
PR middle-end/79222 - missing -Wstringop-overflow= on a stpcpy overflow
PR middle-end/79223 - missing -Wstringop-overflow on a memmove overflow

Martin

gcc-79214.diff


PR preprocessor/79214 -  -Wno-system-header defeats strncat buffer overflow warnings
PR middle-end/79222 - missing -Wstringop-overflow= on a stpcpy overflow
PR middle-end/79223 - missing -Wstringop-overflow on a memmove overflow

gcc/ChangeLog:

	PR preprocessor/79214
	PR middle-end/79222
	PR middle-end/79223
	* builtins.c (check_sizes): Add inlinining context and issue
	warnings even when -Wno-system-headers is set.
	(check_strncat_sizes): Same.
	(expand_builtin_strncat): Same.
	(expand_builtin_memmove): New function.
	(expand_builtin_stpncpy): Same.
	(expand_builtin): Handle memmove and stpncpy.

gcc/testsuite/ChangeLog:

	PR preprocessor/79214
	PR middle-end/79222
	PR middle-end/79223
	* gcc.dg/pr79214.c: New test.
	* gcc.dg/pr79214.h: New test header.
	* gcc.dg/pr79222.c: New test.
	* gcc.dg/pr79223.c: New test.
	* gcc.dg/pr78138.c: Adjust.
The more I think about this, the more I think we should wait. While there is benefit to getting more code checked/verified, we also increase the probability that we issue a bogus warning or issue warnings that are non-obvious to the developer.

Let's queue this for early gcc-8.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]