https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884
Bug ID: 110884
Summary: strncmp false positive with -Wstringop-overread on
coreutils
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
I have this problem with both GCC 13.2.0 (x86-64) and GCC 13.1.1 20230614 (Red
Hat 13.1.1-4) x86-64. I see that bug 104854 was filed for something similar,
but was then closed with a request for "test cases, preferably from real code".
I hope the test case below helps.
I ran into the problem when hacking on GNU coreutils, which needs to deal with
a data structure that on some platforms is a fixed size array suitable for
strnlen, strncmp, etc., and on other platforms is a null-terminated string.
Consider the following code, abstracted from coreutils:
int strncmp (char const *, char const *, unsigned long);
#ifdef FIXED_SIZE_BUFFERS
enum { SIZE = 512 };
#else
enum { SIZE = -1 }; /* no limit */
#endif
_Bool
equal_buffers (char *a, char *b)
{
return strncmp (a, b, SIZE) == 0;
}
Although this code is correct, "gcc -O2 -S t.c" complains:
t.c: In function ‘equal_buffers’:
t.c:12:10: warning: ‘strncmp’ specified bound 18446744073709551615 exceeds
maximum object size 9223372036854775807 [-Wstringop-overread]
12 | return strncmp (a, b, SIZE) == 0;
| ^~~~~~~~~~~~~~~~~~~~
This warning is irrelevant to strncmp since it doesn't matter that (size_t) -1
is greater than any object size; strncmp will stop at the first '\0' byte,
which is what is wanted when FIXED_SIZE_BUFFERS is not defined.
Although I can work around the bug by "#define SIZE 9223372036854775807" on
this platform, that's awkward and confusing.
I assume there are similar problems with strnlen etc.
I think I'll work around the problem by disabling -Wstringop-overread until the
bug is fixed somehow or a better workaround is suggested.
