Re: Cannot find a working 64-bit integer type on Illumos

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

In response to

Responses

Browse pgsql-hackers by date

  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