Re: -Wstringop-overflow warning on compiling info

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)