https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884
--- Comment #3 from Paul Eggert <eggert at cs dot ucla.edu> ---
(In reply to Richard Biener from comment #2)
> you are basically trying to use strcmp (a, b), so why not do that?
strcmp would not work on Fedora 38, or on most current coreutils platforms.
In the full coreutils code, src/system.h contains this definition[1]:
/* n==-1 means unbounded */
#define STREQ_LEN(a, b, n) (strncmp (a, b, n) == 0)
and src/who.c contains this expression[2]:
STREQ_LEN (ttyname_b, utmp_buf->ut_line, UT_LINE_SIZE)
where UT_LINE_SIZE is an enum that is a small positive number on Fedora and
most platforms (where the arguments are UT_LINE_SIZE-byte character arrays,
possibly not null-terminated), and UT_LINE_SIZE is -1 on rare platforms (where
the arguments are char * pointers to null-terminated strings of unbounded
length).
By the way, we tried to work around the GCC false positive this way:
#define STREQ_LEN(a, b, n) \
((n) < 0 ? strcmp (a, b) == 0 : strncmp (a, b, n) == 0)
but this didn't pacify GCC. When N is a negative constant expression, GCC emits
a -Wstringop-overread false positive even on the strncmp call that cannot
possibly be executed.
GCC -Wstringop-overread is supposed to (quoting the GCC manual) "Warn for calls
to string manipulation functions such as ‘memchr’, or ‘strcpy’ that are
determined to read past the end of the source sequence." But the abovementioned
calls to strncpy do not read past the end of the source sequence. So this is a
situation where either GCC's code or its documentation is incorrect.
Getting back to the code that prompted this bug report: strncmp is a primitive
designed for an oddball data structure designed back in the 1970s for tiny
machines. This data structure is a fixed-size character array that either
contains a null-terminated string, or contains all non-null bytes. Nobody liked
this data structure back in the day; people put up with it only because the
machines were so small (and hey! I was there! I wrote code for those
machines!). Nowadays the only code that should use strncmp is code like
coreutils/src/who.c that is still stick with ancient data structures designed
for 1970s machines. People who maintain legacy strncmp-using code should know
what they're doing, and if you know what you're doing (as I hope is the case
with the GNU coreutils maintainers :-) it's OK to pass SIZE_MAX to strncmp.
[1]: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/system.h#n195
[2]: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/who.c#n612
(In reply to Andrew Pinski from comment #1)
> You could use SSIZE_MAX here ...
> That is what 9223372036854775807 is in this case ...
Although that would work on GNU/Linux, POSIX doesn't guarantee it to be
portable, since ssize_t be 32 bits on platforms with 64-bit size_t (and some
historical implementations did that; on these systems syscalls like 'read'
never returned a value greater than 2**31 - 1).
Using (PTRDIFF_MAX < SIZE_MAX ? PTRDIFF_MAX : SIZE_MAX) would work, but is (as
I wrote) awkward. Among other things, the coreutils code uses an enum to record
the size (or -1), and enums can't portably hold values as large as SIZE_MAX or
PTRDIFF_MAX. So we'd have to use a macro instead, and that would have its own
problems.
