On 1/20/22 17:54, Martin Sebor wrote:
The updated patch ensures the tighter bound isn't used to compute
the sprintf result and adds a test to verify that. (This is messy
in the strlen/sprintf pass and should be cleaned up to avoid this
mistake in the future.)
Rested on x86_64-linux.
OK, thanks.
On 1/19/22 18:20, Martin Sebor wrote:
The attached patch suppresses a class of unexpected -Wformat-overflow
(and -truncation) warnings introduced as a result of better range info
with the integration of the strlen pass with Ranger.
The sprintf warning code relies on the strlen pass data to determine
the lengths of string arguments to %s directives. When the data for
a string are present, such as after a strlen call, the length can be
either a constant or, in the case of interest, a range (including
[N, PTRDIFF_MAX - 2] for a string of unbounded length). When absent
because no string call has been seen yet, the string length is
considered to be bounded by the size of the array it's stored in.
This constrains the maximum number of bytes output by the %s directive
and reduces false positives.
The problem this patch addresses is that in the interesting case there
is no logic similar to the last ("no data") case, and so the maximum
number of bytes can be in excess of the size of the array. The patch
does it by computing the size of the object (or member) in which
the string is stored and using its size minus 1 as the upper bound
on the length. To do that, I had to adjust the APIs to pass in
the pointer_query instance of the range_query. The meat of the change
is in the new get_maxbound() function.
There might be opportunities to do better still. I'll try to look
into them if I still have time.
Tested on x86_64-linux.
Martin
