https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84732
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
In general, by inserting their instrumentation the sanitizers cause all sorts
of trouble for middle-end warnings. The usual answer has been to disable
-Werror when using -fsanitize. Personally, I think that's less than optimal
(ideally we want both good static analysis and robust runtime detection), but
sometimes it may be the only viable solution.
The -Wstringop-truncation suppression logic looks for the next statement after
a strncpy call that writes a NUL into the destination (actually, it looks for
an assignment of any value to the destination for now, but that will likely
change in the future). The __builtin___sanitizer_cov_trace_pc() call inserted
by the sanitizer just after the strncpy() call disables the suppression.
__builtin_strncpy (&a.a, arg.0_1, 16);
<bb 4> [local count: 1073741825]:
__builtin___sanitizer_cov_trace_pc ();
There are other similar examples where this can happen (e.g., bug 84624). It
might be possible to deal with some of them either by hardcoding a whitelist of
things to skip over, or by making the logic smart enough to see that some
calls/expressions cannot access (read from) the strncpy destination, or some
combination of the two. Richi has been suggesting the latter approach. The
challenge (for me) is to figure out how to avoid false negatives on things
like:
void f (const char *s)
{
char d[8];
char *p = strncpy (d, s, sizeof d); // want a -Wstringop-truncation here
foo (p); // reads a string from d
d[sizeof d - 1] = '\0';
}
or even:
extern char *p;
void f (const char *s)
{
char d[8];
p = strncpy (d, s, sizeof d); // also want a -Wstringop-truncation here
foo (); // also reads a string from d through p
d[sizeof d - 1] = '\0';
}
