Also ... grison and turaco are emitting warnings that were
not there a couple of days ago:
grison | 2024-12-04 17:10:09 | reconstruct.c:701:33: warning: passing
argument 2 of 'copy_file_range' from incompatible pointer type
[-Wincompatible-pointer-types]
turaco | 2024-12-04 16:15:11 | reconstruct.c:701:61: warning: passing
argument 2 of 'copy_file_range' from incompatible pointer type
[-Wincompatible-pointer-types]
The code they are complaining about is from ac8110155 ("Allow using
copy_file_range in write_reconstructed_file") back in April:
off_t off = offsetmap[i];
...
wb = copy_file_range(s->fd, &off, wfd, NULL, BLCKSZ - nwritten,
0);
Now, on my Linux box "man copy_file_range" saith
ssize_t copy_file_range(int fd_in, loff_t *off_in,
int fd_out, loff_t *off_out,
size_t len, unsigned int flags);
So apparently, "off_t" was the same as "loff_t" before 962da900a,
but it no longer is the same on 32-bit machines. (In any case,
if all machines that have copy_file_range define it like this,
perhaps we ought to be declaring this variable as loff_t not off_t?)
Digging a bit deeper, the full warning report is
reconstruct.c: In function "write_reconstructed_file":
reconstruct.c:701:33: warning: passing argument 2 of "copy_file_range" from
incompatible pointer type [-Wincompatible-pointer-types]
wb = copy_file_range(s->fd, &off, wfd, NULL, BLCKSZ - nwritten, 0);
^~~~
In file included from reconstruct.c:15:
/usr/include/unistd.h:1107:49: note: expected "__off64_t *" {aka "long long int
*"} but argument is of type "off_t *" {aka "long int *"}
ssize_t copy_file_range (int __infd, __off64_t *__pinoff,
~~~~~~~~~~~^~~~~~~~
Since these are 32-bit machines, "long int" is 32 bits (confirmed from
their configure results), which means "off_t" is only 32 bits, which
really sounds quite broken. I thought it was 64 bits pretty much
everywhere nowadays. Did 962da900a cause that? Maybe that explains
the Perl library compatibility problems these machines are reporting?
regards, tom lane
