[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31b53a8d-7cf4-b3a3-371f-a5723963383e@cs.ucla.edu>
Date: Fri, 30 Jun 2023 12:44:23 -0700
From: Paul Eggert <eggert@...ucla.edu>
To: libc-coord@...ts.openwall.com, Jonathan Wakely <jwakely@...hat.com>
Cc: Rich Felker <dalias@...c.org>, linux-man@...r.kernel.org,
musl@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Re: [libc-coord] Re: regression in man pages for interfaces using
loff_t
On 2023-06-30 01:02, Jonathan Wakely wrote:
> 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.
Sorry, I missed that detail. Still, the argument stands. On legacy
32-bit platforms without -D_FILE_OFFSET_BITS=64, calls will still work
if they pass null pointers to copy_file_range, a common case in my
experience. The calls that don't, will get typecheck errors or warnings,
and that's good enough to address the issue.
> 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).
That's good! People should be using -D_FILE_OFFSET_BITS=64 if they use
these functions, and the typecheck errors and/or warnings will remind
them. The man pages don't need to (and shouldn't) document what happens
if you call these functions on legacy 32-bit platforms without first
defining _FILE_OFFSET_BITS to be 64.
> People miss footnotes.
OK, let's make the point more prominently, at the start of the man page.
Proposed patch attached. This patch should work for musl as well as for
glibc.
View attachment "0001-off64_t-prefer-off_t-for-splice-etc.patch" of type "text/x-patch" (8355 bytes)
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.
