mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: linux-man@vger.kernel.org, musl@lists.openwall.com,
	libc-alpha@sourceware.org, libc-coord@lists.openwall.com
Subject: [musl] Re: regression in man pages for interfaces using loff_t
Date: Wed, 28 Jun 2023 15:15:26 -0400	[thread overview]
Message-ID: <20230628191525.GS20050@brightrain.aerifal.cx> (raw)
In-Reply-To: <add1e27e-e10c-e70d-ed5e-85bb0d4d4101@cs.ucla.edu>

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

  reply	other threads:[~2023-06-28 19:15 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 17:53 [musl] " Rich Felker
2023-06-28 18:21 ` [musl] " Paul Eggert
2023-06-28 19:15   ` Rich Felker [this message]
2023-06-30  7:11     ` Paul Eggert
2023-06-30  8:02       ` [musl] Re: [libc-coord] " Jonathan Wakely
2023-06-30  8:14         ` Jonathan Wakely
2023-06-30  8:30           ` Sam James
2023-06-30 19:44         ` Paul Eggert
2023-07-02  1:18           ` A. Wilcox
2023-07-02 19:21             ` Paul Eggert
2023-07-03 18:16               ` Jakub Wilk
2023-07-03 21:35                 ` Paul Eggert
2023-07-08 17:03                   ` Alejandro Colomar
2023-07-09  6:07                     ` [musl] [PATCH v4] off64_t: prefer off_t for splice, etc Paul Eggert
2023-07-09  6:16                       ` [musl] Re: [libc-coord] " Sam James
2023-07-15 15:08                         ` Alejandro Colomar
2023-07-15 18:35                           ` Rich Felker
2023-07-15 20:01                             ` Paul Eggert
2023-07-16  0:35                             ` Alejandro Colomar
2023-07-16  0:39                               ` Alejandro Colomar
2023-06-30 23:37       ` [musl] Re: regression in man pages for interfaces using loff_t Rich Felker
2023-07-01  7:24         ` [musl] Re: [libc-coord] " Paul Eggert
2023-07-01 13:36           ` Szabolcs Nagy
2023-07-01 23:02             ` Paul Eggert
2023-07-01 14:32           ` Rich Felker
2023-07-01 18:45             ` Alejandro Colomar
2023-07-01 23:06             ` Paul Eggert
2023-06-28 19:19   ` Szabolcs Nagy
2023-06-28 19:28   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230628191525.GS20050@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-coord@lists.openwall.com \
    --cc=linux-man@vger.kernel.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).