From: Rich Felker <dalias@libc.org>
To: linux-man@vger.kernel.org
Cc: musl@lists.openwall.com, libc-alpha@sourceware.org,
libc-coord@lists.openwall.com
Subject: [musl] regression in man pages for interfaces using loff_t
Date: Wed, 28 Jun 2023 13:53:30 -0400 [thread overview]
Message-ID: <20230628175329.GA16113@brightrain.aerifal.cx> (raw)
https://github.com/mkerrisk/man-pages/commit/9bebb17e5b5794e495ba8e6c0a75266c65b9d2d7
https://github.com/mkerrisk/man-pages/commit/76c5631fb442f1c7c0b5ec8c653e84f2997249c8
and perhaps related changes for other functions introduced a breaking
change in the documentation for the way applications should call libc
functions for Linux-specific APIs that always take a 64-bit file
offset. The type for this is loff_t, not off64_t, which is an LFS64
type which only exists when LFS64 is supported and enabled.
Applications following the documentation change will not compile on
musl libc, and in theory would not compile even on glibc if it
followed reasonable policy for exposing visibility of off64_t, though
it might happen to be that on glibc, all feature profiles that expose
the relevant functions also expose LFS64.
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.
For an example of the breakage resulting from following the change in
documentation, see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
Please revert this.
Rich
next reply other threads:[~2023-06-28 17:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-28 17:53 Rich Felker [this message]
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 ` [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=20230628175329.GA16113@brightrain.aerifal.cx \
--to=dalias@libc.org \
--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).