From: Rich Felker <email@example.com>
To: Paul Eggert <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org,
Subject: Re: [musl] Re: regression in man pages for interfaces using loff_t
Date: Fri, 30 Jun 2023 19:37:05 -0400 [thread overview]
Message-ID: <20230630233705.GW4163@brightrain.aerifal.cx> (raw)
On Fri, Jun 30, 2023 at 12:11:20AM -0700, Paul Eggert wrote:
> On 2023-06-28 12:15, Rich Felker wrote:
> >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
> Although we won't have files with 2**63 bytes any time soon, this is
> the best argument for preferring "loff_t" to "off64_t".
> But come to think of it, it'd be better to document the type simply
> as "off_t", with a footnote saying the equivalent of "this assumes
> that on 32-bit glibc platforms you compile with
> -DFILE_OFFSET_BITS=64 like any sane person would." The intent really
> is off_t here, and that will remain true even if off_t ever widens
> past 64 bits.
I would love that these functions just take normal off_t. However,
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.
> I don't see why not. For example, POSIX-2018 requires int32_t even
> though C17 says it's optional. So there's precedent for POSIX
> adopting a type that's optional elsewhere.
That's the other way around and not related to what I was talking
> Also, to POSIX loff_t is just as optional as off64_t is. glibc
> defines neither type if the app #defines _POSIX_C_SOURCE as POSIX
> requires. So from a standardization viewpoint there's no reason to
> prefer one type over the other.
From a standardization viewpoint, a more general standard does not
want to adopt things from a more specific standard that might have
hidden requirements or tie-in with other parts of the more specific
standard that the more general one would not want to be tied down to.
> >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.
> I'm not sure what the point is here, as far as standardization goes.
> Neither ISO C nor POSIX use loff_t, and neither is likely to ever
> use it: ISO C won't even adopt off_t much less loff_t, and POSIX
> works just fine with off_t and doesn't need loff_t. (The same goes
> for off64_t of course.)
Noobody's talking about if ISO C would adopt loff_t. I'm talking about
how an interface using a type that's under somebody else's
jurisdiction is problematic to adoption. loff_t having no precedent
except these Linux-introduced functions is why it's not problematic.
However I don't particular like or want to argue "for loff_t". What I
care about is that published interface definitions don't get changed
unilaterally by someone writing docs and made incompatible with
If we want to work together for something mutually acceptable and
better than loff_t, that'd be fine with me too. But it seems
independent of fixing the immediate regression.
> But anyway this is all moot if we simply document the arguments as
> off_t with a footnote.
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.
next prev parent reply other threads:[~2023-06-30 23:37 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
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 ` Rich Felker [this message]
2023-07-01 7:24 ` [musl] Re: [libc-coord] Re: [musl] Re: regression in man pages for interfaces using loff_t 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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).