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

On Thu, Dec 5, 2024 at 8:41 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So apparently, "off_t" was the same as "loff_t" before 962da900a,
> but it no longer is the same on 32-bit machines.

Right, that's really weird.

> (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?)

Hmm. FreeBSD just has off_t in its declaration, but off_t is always
64 bit, and I don't think it knows about loff_t.

I guess copy_file_range() didn't follow the usual plan of respecting
_FILE_OFFSET_BITS, so there's no 32 bit off_t support for it in libc,
hence they needed to invent (or leak from the kernel?) loff_t. I
don't think we should change that, because we use AC_SYS_LARGEFILE to
find that we need -D_FILE_OFFSET_BITS=64 on 32 bit systems, so off_t
should be the same as loff_t. If something weren't broken
somewhere... Somehow it's getting lost?

> 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?

Right, that definitely should upset Perl, as it changes the size of
struct stat and all kinds of stuff, probably.

The affected systems are mostly running ancient OSes, and lapwing is
32 bit x86, so it's not only armv7. Current 32 bit x86 systems are
working fine. Maybe I should boot up a Debian 7 x86 build (my
attempts to run ancient Debian/armv7 on qemu last night failed, x86
sounds easier...) The armv7 systems except turaco are running the
same era of Debian as lapwing, but I'm not sure what turaco is.