[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230701143205.GX4163@brightrain.aerifal.cx>
Date: Sat, 1 Jul 2023 10:32:05 -0400
From: Rich Felker <dalias@...c.org>
To: Paul Eggert <eggert@...ucla.edu>
Cc: libc-coord@...ts.openwall.com, linux-man@...r.kernel.org,
musl@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Re: Re: [libc-coord] Re: Re: regression in man pages
for interfaces using loff_t
On Sat, Jul 01, 2023 at 12:24:27AM -0700, Paul Eggert wrote:
> 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.
These are not "new APIs" from the standpoint of glibc, which already
had them in 32-bit-off_t API profiles and can't be expected just to
remove them.
I'm all for using off_t in new interfaces. But unless glibc folks
agree, I am not for redefining interface types in a way that breaks
one of their supported profiles any more than I am for redefining
interface types in the way that broke things with musl.
> >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.
I don't know if I'm not communicating well here or what. This topic
was about why we don't use off64_t for these interfaces (because
off64_t is governed by LFS64) not a reason not to use off_t.
In explaining this I cited an analogy to why the fseeko/ftello
interfaces were doomed not to be accepted in ISO C (if POSIX had made
fseekll and ftellll using long long instead, there would have been a
clear path to putting them in C without pulling in POSIX types). That
has nothing to do with your proposal to just use off_t. Of course
using off_t in new custom interfaces that build on an underlying POSIX
base is fine and is the preferred way to do things.
> >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.
That's simply not the case.
1. The spec was that apps declare loff_t objects and pass pointers to
those to some of the interfaces. That works on all existing
implementations and profiles.
2. The spec was silently changed to be that apps declare off64_t
objects and pass those instead. This breaks on musl which
intentionally does not have LFS64 types/interfaces.
3. Under your proposal, the spec is that apps declare off_t objects
and pass pointers to those. This produces a pointer type mismatch,
and buffer overflow, if building with glibc and (still default)
_FILE_OFFSET_BITS=32.
Of course glibc could try to remedy this by somehow masking these
functions when _FILE_OFFSET_BITS=32 so they can't get used. If they
want to do that, great. However, the documentation does not specify a
particular glibc version, and if applications followed your proposed
change to the documentation, they would end up with dangerously broken
code when compiled on any existing glibc out in the wild with
_FILE_OFFSET_BITS=32.
This is why the only safe and reasonable thing to do, without an
extensive consensus process working to understand and assess the
impact of a change, is NOT TO MAKE CHANGES TO EXISTING INTERFACE
SPECIFICATIONS. It's really unsettling that this was done unilaterally
in such an important source of documentation as linux-man. Unless
glibc folks come up with a way to get on board with changing it to
off_t like you want, I do not want to get into another round of making
changes to "improve" something that was wrong about how the interface
was specified before. I just want to revert the breakage and establish
that this kind of breakage should not happen.
Rich
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.
