From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12648 invoked from network); 30 Jun 2023 08:33:01 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 30 Jun 2023 08:33:01 -0000 Received: (qmail 5482 invoked by uid 550); 30 Jun 2023 08:32:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5444 invoked from network); 30 Jun 2023 08:32:55 -0000 References: <20230628175329.GA16113@brightrain.aerifal.cx> <20230628191525.GS20050@brightrain.aerifal.cx> <8e65a459-a933-38b4-5f82-f7016c107d91@cs.ucla.edu> User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: Jonathan Wakely Cc: libc-coord@lists.openwall.com, Rich Felker , linux-man@vger.kernel.org, musl@lists.openwall.com, libc-alpha@sourceware.org Date: Fri, 30 Jun 2023 09:30:57 +0100 In-reply-to: Message-ID: <87a5wh2vvc.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain Subject: [musl] Re: [libc-coord] Re: regression in man pages for interfaces using loff_t Jonathan Wakely via Libc-alpha writes: > On Fri, 30 Jun 2023 at 09:02, Jonathan Wakely wrote: >> >> On Fri, 30 Jun 2023 at 08:11, 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 >>> > possible). >>> >>> 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. >>> >>> All the apps I know that use the syscalls in question simply pass >>> values that fit in off_t to these functions, and this will work >>> regardless of whether these apps are compiled with 64- or (horrors!) >>> 32-bit off_t. Admittedly the footnote solution would not be perfect, but >>> it's good enough, and it would sidestep the loff_t vs off64_t confusion. >> >> >> For APIs like copy_file_range(2) and splice(2) the arguments are >> loff_t* so you can't just "pass arguments that fit in off_t" to >> them. You have to get the pointer type correct, because writing >> 64-bits through a 32-bit off_t would be bad. And in C++ it won't >> even compile unless you get the pointer types exactly right (C >> compilers will typically allow the mismatch with just a warning). >> >> People miss footnotes. I would really prefer if the signature shown >> in the man page used a type that will actually compile. If it shows >> off_t, that won't compile for 32-bit systems without LFS support >> enabled. > > Apologies for sending the mail above as HTML - replying as text/plain > for those it didn't reach. Yes, please. The footnote is likely to be misunderstood at best (if people even see it, they'll think it's some obscure portability issue and try to #ifdef or something). Apparently we got confused by this before as well: https://github.com/gentoo/portage/commit/1a7aeb58c4e687e4d4012054b56373f27941a067 (https://bugs.gentoo.org/617778), so I'll need to look at that now too.