[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230628191525.GS20050@brightrain.aerifal.cx>
Date: Wed, 28 Jun 2023 15:15:26 -0400
From: Rich Felker <dalias@...c.org>
To: Paul Eggert <eggert@...ucla.edu>
Cc: linux-man@...r.kernel.org, musl@...ts.openwall.com,
libc-alpha@...rceware.org, libc-coord@...ts.openwall.com
Subject: Re: regression in man pages for interfaces using loff_t
On Wed, Jun 28, 2023 at 11:21:39AM -0700, Paul Eggert wrote:
> On 2023-06-28 10:53, Rich Felker wrote:
> >The whole reason loff_t exists is to avoid this problem and make a
> >type that's "always full width offset, regardless of _FILE_OFFSET_BITS
> >or _LARGEFILE64_SOURCE" to match with the kernel expectation for these
> >interfaces.
>
> Why can't off64_t be that type, as it is in glibc? I'm not seeing
> why we need two names for the same type.
As for why off64_t is not an appropriate type, it's defined by and
associated with the LFS64 summit and the related intefaces, and
governed by them. Using it makes these interfaces non-standardizable,
because no standard is going to adopt a function whose public
interface depends on another optional thing they don't want to
mandate. This is exactly the problem why ISO C is stuck with the
broken and unusable fseek/ftell that take long, and hasn't adopted
fseeko/ftello from POSIX -- their public interfaces use the
POSIX-governed type off_t, and as such, ISO C adopting them without
adopting the whole POSIX off_t is out of the question.
As a particular practical concern, applications performing
configure-like tests may use the existence of an off64_t type to
conclude that the LFS64 API is supported on the system they're being
built on. This is not the case on musl (technically, it's still
supported at build-time with explicit -D_LARGEFILE64_SOURCE, but that
is slated for removal once known issues are fixed) and we don't want
to mislead applications that it is.
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). loff_t encodes no such assumption in its name or
specification; it's just "long offset" whatever that is, and an
implementation is free (as we do on musl) to just define it as off_t.
But more fundamentally, the problem here is that a documented
interface was just arbitrarily changed in an incompatible way, with no
process or accountability. The documented interface is what
applications are supposed to be writing to, and what alternate
implementations aiming to be compatible with applications using the
interfaces are supposed to match. Changing that out from under us
later is Not Nice.
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.
