Re: [PATCH] relax -Wformat-overflow for precision ranges (PR 79275)

[Jeff Law <law at redhat dot com>]

On 02/01/2017 05:40 PM, Martin Sebor wrote:
> 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.
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.

> 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).
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?

jeff