https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104746
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |REOPENED
--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> ---
Why can't we leave this open? There have been VRP bugs open since 2005. There
was no intent to fix them back then, but they identify opportunities for
improvement.
I think this is a good placeholder for improvements in analyzing the parameters
of the warning. We can make more effort when there is more than one parameter
to see if the information can be further refined.
_4 = i_6(D) + j_7(D);
if (_4 > 19)
goto <bb 4>; [INV]
else
goto <bb 5>; [INV]
<bb 5> :
__builtin_sprintf (&a, "%u%u", i_6(D), j_7(D));
i_6 and j_7 are both understood to be [0,19], and it wouldn't take much more
work to find if there is a relationship between them, and refine the values.
They appear together in one statement _4 = i_6 + j_7, and _4 is known to be
[0,19] at the warning location.
so [0,19] = i_6 + j_7
we can ask what the range of i_6 or j_7 is if the other one is refined.
[10,99] will create 2 characters of output, you can ask if i_6 is [10,19],
whats the range of j_7, and it will give you [0,9]. And then the warning
doesn't need to trigger. Likewise for i_6 computed from j_7 = [10, 19].
This could be generalized using [100,999] for 3 character outputs, [1000, 9999]
is 4 characters, etc. And doing a bit more work trying to analyze the
parameters.
Those bits are all there now. This could be in the next release.
I'd even argue we should probably split this into 2 reports. The earlier
warning on:
char *path = malloc(strlen(dirname) + strlen(result) + 2);
sprintf(path, "%s/%s", dirname, result);
Seems like a different opportunity in which we could track/associate strlen
results with the string. ie
result_17 = malloc (_5);
sprintf (result_17, "%s", suffix_14);
_6 = strlen (dirname_13);
_7 = strlen (result_17);
_8 = _6 + _7;
_9 = _8 + 2;
path_20 = malloc (_9);
sprintf (path_20, "%s/%s", dirname_13, result_17);
_6 is length of dirname_13, and _7 is length of result_17, Then we malloc an
object that is _6 + _7 + 2 and copy those 2 strings into it.
With the appropriate pointer/string/strlen/malloc associations it seems
deterministically knowable that we can avoid that warning too.
Any false positive we can potentially eliminate with some additional analysis
is worth tracking and considering IMO. This PR is on the list of PRs I track
for possible future improvements.
