https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |84774
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
I feel like I have seen this translation unit before. The warning is by
design: for calls to strcpy with the same destination and source arrays, where
the algorithm cannot prove that an overlap doesn't occur it issues a "may
overlap" kind of a warning. The offset ranges make it clear (to me at least)
that the warning algorithm thinks the overlap is possible but not inevitable.
For example, this triggers it:
void f (char *p, int i)
{
if (i < 0)
i = 0;
char *q = p + i;
__builtin_strcpy (q, p);
}
t.c:10:3: warning: ‘__builtin_strcpy’ accessing 1 byte at offsets [0,
2147483647] and 0 may overlap 1 byte at offset 0 [-Wrestrict]
10 | __builtin_strcpy (q, p);
| ^~~~~~~~~~~~~~~~~~~~~~~
The logic behind the decision is that since using strcpy to copy within the
same array is only safe when one knows the length of the source string (in
addition to the distance between the offsets into the array), using a "bounded"
function such as memcpy or even strncpy would be more appropriate: it would
make the constraints explicit without sacrificing efficiency or readability.
GCC 8 doesn't issue the warning here because the bug fixed in r268048 on the
trunk but not yet backported to gcc-8-branch gets in the way: the offset in the
POINTER_PLUS_EXPR is in the anti-range ~[INT_MAX + 1, INT_MIN] which GCC 8
doesn't handle correctly. I haven't backported r268048 to GCC 8 yet but I
don't think this warning is a reason not to. Richard, let me know if you feel
otherwise.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict
