On 2023-06-30 16:37, Rich Felker wrote:
glibc made it so off_t can be 32- or 64-bit depending on _FILE_OFFSET_BITS, and if it's 32-bit, there is no matching version of the libc syscall wrappers for these functions. It seems to have been a conscious choice not to make any.
Yes, _FILE_OFFSET_BITS=32 is obsolescent. Among other things in GNU/Linux it is guaranteed to stop working in the year 2038, because you can't have 64-bit time_t without also having 64-bit off_t. There is no interest in supporting _FILE_OFFSET_BITS=32 for new APIs, which these are.
I'm talking about how an interface using a type that's under somebody else's jurisdiction
I don't understand why jurisdiction matters here. Although off_t is under someone else's (POSIX's) jurisdiction, that doesn't mean the Linux man pages can't use POSIX-specified types like off_t.
This is still changing the documentated signature, which isn't really nice, and would not be compatible with glibc unless glibc went out of its way to hide those functions when _FILE_OFFSET_BITS is 32.
I don't see any incompatibility with glibc and the changes I proposed. The changes merely weaken the spec in the man pages in an area where the spec should be weakened. glibc is compatible with the spec before it was changed to use off64_t, it's compatible with the spec now that it uses off64_t, and it would continue to be compatible with the spec if the proposed changes are adopted.
