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] |
On 02/01/2017 05:40 PM, Martin Sebor wrote:
So as I mentioned in my message to Joseph, I'm going to go with Joseph & Jakub's view that this should be considered a regression.On 01/31/2017 03:33 PM, Jeff Law wrote:On 01/30/2017 02:28 PM, Martin Sebor wrote:Bug 79275 - -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c points out a false positive found during a Glibc build and caused by the checker using the upper bound of a range of precisions in string directives with string arguments of non-constant length. The attached patch relaxes the checker to use the lower bound instead when appropriate. Martin gcc-79275.diff PR middle-end/79275 - -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c gcc/testsuite/ChangeLog: PR middle-end/79275 * gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: New test. * gcc.dg/tree-ssa/pr79275.c: New test. gcc/ChangeLog: PR middle-end/79275 * gimple-ssa-sprintf.c (get_string_length): Set lower bound to zero. (format_string): Tighten up the range of output for non-constant strings and correct the expected range for wide non-constant strings.My general inclination is to ask this to wait for gcc-8 as it is not a regression, but instead a false positive in a new warning.
Presumably the argument against simply giving up and not checking at all is that by assuming length 1, we can still check all the other arguments and perhaps still give a warning if the sprintf overflows when the unbound string is essentially ignored?My rationale for zero and one for strings of unknown length was to try to avoid false positives. The checker does use the size of the array when a string of unknown length points to one as the likely length. That's run into the expected pushback but at least there is (what I consider) a defensible rationale for it (the string could potentially be as long as the array, otherwise why make the array that big?) It also uses the length of the longest of the strings an argument is known to point to, on the same basis. My biggest concern with being more aggressive than that (besides the pushback) is that I can't think of a good function to compute the size (it can't very well be a constant).
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |