https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=83688,
| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=83859
--- Comment #11 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning will go away once -Wrestrict is implemented for sprintf, hopefully
in GCC 9 (the patch I submitted in July didn't make it to GCC 8:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00036.html), and the handling for
the built-in functions removed from the front-end. This is being tracked in
bug 83688.
Until then, the only way to avoid the warning that I can think of is to exclude
from checking arguments passed through the ellipsis, but that will result in
some false negatives for sprintf et al. So the question is: do the benefits of
the warning outweigh the cost of the false positives.
The potential for false positives here also isn't limited to sprintf. It's a
general problem that affects user-defined functions as well. For example:
$ cat z.c && gcc -S -Wall z.c
void f (char* restrict, const char* restrict, const void*);
void g (char *s)
{
f (s, "", s);
}
z.c: In function ‘g’:
z.c:5:3: warning: passing argument 1 to restrict-qualified parameter aliases
with argument 3 [-Wrestrict]
f (s, "", s);
^
The only way to avoid these false positives (and negatives) is to add some
annotation to let users indicate how each argument is used (e.g., such as the
attributes read_only and write_only that I've been working on). This is being
tracked in bug 83859.
