[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Jul 2023 00:24:27 -0700
From: Paul Eggert <eggert@...ucla.edu>
To: libc-coord@...ts.openwall.com, Rich Felker <dalias@...c.org>
Cc: linux-man@...r.kernel.org, musl@...ts.openwall.com,
libc-alpha@...rceware.org
Subject: Re: Re: [musl] Re: regression in man pages for
interfaces using loff_t
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
