[musl] Re: [libc-coord] Re: [musl] Re: regression in man pages for interfaces using loff_t

[Paul Eggert <eggert@cs.ucla.edu>]

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.