On 2023-06-28 12:15, Rich Felker wrote:
> There's also the problem that off64_t is "exactly 64-bit" which makes
> it unsuitable as an interface type for cross-platform functions where
> one could imagine the native type being larger (rather horrifying but
> possible).
Although we won't have files with 2**63 bytes any time soon, this is the
best argument for preferring "loff_t" to "off64_t".
But come to think of it, it'd be better to document the type simply as
"off_t", with a footnote saying the equivalent of "this assumes that on
32-bit glibc platforms you compile with -DFILE_OFFSET_BITS=64 like any
sane person would." The intent really is off_t here, and that will
remain true even if off_t ever widens past 64 bits.
All the apps I know that use the syscalls in question simply pass
values that fit in off_t to these functions, and this will work
regardless of whether these apps are compiled with 64- or (horrors!)
32-bit off_t. Admittedly the footnote solution would not be perfect, but
it's good enough, and it would sidestep the loff_t vs off64_t confusion.
For APIs like copy_file_range(2) and splice(2) the arguments are loff_t* so you can't just "pass arguments that fit in off_t" to them. You have to get the pointer type correct, because writing 64-bits through a 32-bit off_t would be bad. And in C++ it won't even compile unless you get the pointer types exactly right (C compilers will typically allow the mismatch with just a warning).
People miss footnotes. I would really prefer if the signature shown in the man page used a type that will actually compile. If it shows off_t, that won't compile for 32-bit systems without LFS support enabled.