--- Comment #3 from Martin Sebor <msebor at gcc dot> ---
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

  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';

Reply via email to