From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Japin Li <japinli(at)hotmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Cannot find a working 64-bit integer type on Illumos |
Date: | 2024-12-04 19:41:19 |
Message-ID: | 2385947.1733341279@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michał Kłeczek | 2024-12-04 19:49:36 | Re: Proposal: Role Sandboxing for Secure Impersonation |
Previous Message | Peter Eisentraut | 2024-12-04 19:29:57 | Re: Potential ABI breakage in upcoming minor releases |