From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Tomas Vondra <tomas@vondra.me>, Peter Eisentraut <peter@eisentraut.org>,
        Heikki Linnakangas <hlinnaka@iki.fi>, Japin Li <japinli@hotmail.com>,
        Andres Freund <andres@anarazel.de>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Cannot find a working 64-bit integer type on Illumos
In-reply-to: <2276817.1733293172@sss.pgh.pa.us>
References: <ME3P282MB3166F9D1F71F787929C0C7E7B6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM> <20240322165305.6zrtxcmzdrywvmsu@awork3.anarazel.de> <ME3P282MB3166D876E9CB83009727A5ECB6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM> <944094.1711128356@sss.pgh.pa.us> <CA+hUKG+CR05ACFujUbeAd-yM+nNJBSpnyB=q3vbriCJuoSu9Ag@mail.gmail.com> <1229869.1711160593@sss.pgh.pa.us> <CA+hUKG+ZwX-reVMHak3yo-63rrh9AJwEVGW4rCbsoLeSKO54Pg@mail.gmail.com> <7cf1dcb7-306f-4418-bf25-bdc75130db10@eisentraut.org> <CA+hUKGKXEdVSfR6UHXfR3tSQ+TfBNk-ssYmO2F0wCdw7qcx86Q@mail.gmail.com> <d8d68452-7195-41cf-a31b-e660f5ac6e75@iki.fi> <CA+hUKG+rYp-=fTP5kjRmnfPq7YgK-e=J+gJxBvKarkPVzLwQmQ@mail.gmail.com> <0e2cc7af-f0c0-418c-b640-e5eb03eaa6e6@eisentraut.org> <CA+hUKGL7YprY+mkWg-9rVkrzkeC62ppdzyb7KcPp9tcff_5F3Q@mail.gmail.com> <CA+hUKGK7WQX3nTuYbiiGZFcV70CqbmBx4VUOnDy6ZGm1v=qGqQ@mail.gmail.com> <50a4c05e-c43e-4e7e-95d2-4b16493073ed@eisentraut.org> <CA+hUKGJ=6wVNNdv9XAUwNv+hhPCW3FzFEkrr6i5axx090vEmcQ@mail.gmail.com> <CA+!
 ! hUKGKRM1vk2Bd=B7O9SKeiz6c=KUB08N0M9fHVq057u9uhJw@mail.gmail.com> <2276817.1733293172@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 04 Dec 2024 01:19:32 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2385946.1733341279.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 04 Dec 2024 14:41:19 -0500
Message-ID: <2385947.1733341279@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2385947.1733341279%40sss.pgh.pa.us>
Precedence: bulk

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: pass=
ing argument 2 of 'copy_file_range' from incompatible pointer type [-Winco=
mpatible-pointer-types]
 turaco        | 2024-12-04 16:15:11 | reconstruct.c:701:61: warning: pass=
ing argument 2 of 'copy_file_range' from incompatible pointer type [-Winco=
mpatible-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 =3D offsetmap[i];
            ...
                wb =3D copy_file_range(s->fd, &off, wfd, NULL, BLCKSZ - nw=
ritten, 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" fro=
m incompatible pointer type [-Wincompatible-pointer-types]
     wb =3D 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 lon=
g 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