https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
There isn't going to be a good solution that makes all folks happy - we'd
either have false negatives or false positives. It is true that we're
accumulating more and more cases where the user gets the impression we want to
warn about
int a[16];
void foo (size_t len)
{
memset (a, 0, len);
}
like
warning: memset called with unbound 'len' argument to buffer of size 16
for example we do not diagnose
int a[2];
void foo (unsigned len)
{
if (len == 1 || len == 20)
__builtin_memset (a, 0, len);
}
even though with len == 20 this is out of bounds. Instead we only
diagnose if both possible accesses are out of bounds but we fail
to see that in the 'else' case we do not call memset at all. What's
the real difference to the len == 1 case that makes us to not
emit the diagnostics here?
What we traditionally consider as "always" and "maybe" is also blurry
with more and more IPA optimization (functions are always only "maybe"
executed).
What static analyzers and fuzzers do is isolate every possible path,
sensible or not, and diagnose those. We're getting closer to that
(but every non-sensical isolated path also consumes object space).
