https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99075
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
CC| |msebor at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The term "string manipulation" is used in -Wstringop-overflow where the text in
-Wstringop-overread comes from. The functions are indeed declared in
<string.h> which the C standard refers to as a "string handling header" and
describes as:
The header <string.h> declares one type and several functions, and defines one
macro useful for manipulating arrays of character type and other objects
treated as arrays of character type.
That's also where "string manipulation" came from.
-Wstringop-overread is issued for any string (or raw memory) function that
might read past the end of an array. memchr and memcpy are just a couple of
examples. It applies to memcmp and strcmp as well, and others. For example:
$ cat t.c && gcc -S t.c
const char a[] = { 1, 2, 3 };
volatile int i;
void f (void)
{
i = __builtin_memcmp (a, a + 1, 3);
i = __builtin_strcmp (a, a + 1);
}
t.c: In function ‘f’:
t.c:7:7: warning: ‘__builtin_memcmp’ specified bound 3 exceeds the size 2 of
unterminated array [-Wstringop-overread]
7 | i = __builtin_memcmp (a, a + 1, 3);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 1, 2, 3 };
| ^
t.c:8:7: warning: ‘__builtin_strcmp’ argument missing terminating nul
[-Wstringop-overread]
8 | i = __builtin_strcmp (a, a + 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 1, 2, 3 };
| ^
I would not be opposed to rewording the text (or replacing memcpy with strcpy)
if someone wanted to do make that change but using the term "memory
manipulation" instead wouldn't be correct. The manual has this:
Warn for calls to string manipulation functions such as memchr, or strcpy
that are determined to read past the end of the source sequence.
so that would work. In any event, I see nothing wrong with how it's phrased
now to consider this report valid.
