On Fri, Jan 23, 2026 at 12:11:27AM +0100, Patrice Dumas wrote:
> > I haven't understand fully all the reasons for the changes to types in
> > this code. I expect this problem is a hangover from people deciding to
> > convert from unsigned integer types to signed integer types or vice versa.
> >
> > (In commit 219bed49caf262a (2012-11-17), types were changed from long
> > (signed)
> > to size_t (unsigned). This was further changed in the commit above.)
>
> I can say for the changes I made. The idea was to avoid mixing signed
> and unsigned integers because it can easily lead to bugs because going
> through 0 may get unnoticed, and also probably because it is undefined
> behaviour. When this is anavoidable, at least add something that shows
> that a conversion is needed or such.
Yes, that sounds like a good idea. Your changes make sense, as far as I can
tell. It's probably good to use signed integer types in more places, where
possible. It's just led to a compiler warning in this case but there is
likely no real problem that wasn't there before.
I can replicate the gcc warning with a very short program:
---------------------------
#include <unistd.h>
#include <stdlib.h>
char buf[1000];
int
main (void)
{
ssize_t n = -2;
read (0, buf, n);
}
---------------------------
$ cc tmp.c
tmp.c: In function ‘main’:
tmp.c:11:3: warning: ‘read’ specified size 18446744073709551614 exceeds maximum
object size 9223372036854775807 [-Wstringop-overflow=]
11 | read (0, buf, n);
| ^~~~~~~~~~~~~~~~
tmp.c:4:6: note: destination object allocated here
4 | char buf[1000];
| ^~~
In file included from tmp.c:1:
/usr/include/unistd.h:371:16: note: in a call to function ‘read’ declared with
attribute ‘access (write_only, 2, 3)’
371 | extern ssize_t read (int __fd, void *__buf, size_t __nbytes) __wur
| ^~~~
9223372036854775807 is 2**63 - 1. This number is not so important but evidently
is the maximum number of bytes that should be read.
18446744073709551614 is 2**64 - 2. This is the result of casting a small
negative integer to an unsigned type. This results in a very large number.
Where the compiler gets -2 from (in info/filesys.c) is a mystery to me.
(According to an unreliable-looking StackOverflow answer[1] that looks like it
was written by AI, 18446744073709551614 is also 2 * PTRDIFF_MAX, where
PTRDIFF_MAX
is the maximum size of a C object. It's unclear if this has any relevance.
[1]
https://stackoverflow.com/questions/79738323/gcc-warning-memcpy-specified-bound-18446744073709551614-exceeds-maximum-objec)
