Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 15 Jul 2023 14:35:11 -0400
From: Rich Felker <>
To: Alejandro Colomar <>
Cc: Paul Eggert <>, Sam James <>,,,
	"A . Wilcox" <>,
	Jonathan Wakely <>,,, Szabolcs Nagy <>,
	Jakub Wilk <>
Subject: Re: [musl] Re: [PATCH v4] off64_t: prefer off_t for
 splice, etc.

On Sat, Jul 15, 2023 at 05:08:18PM +0200, Alejandro Colomar wrote:
> Hi Paul, Sam, and Rich,
> On 2023-07-09 08:16, Sam James wrote:
> > 
> > Paul Eggert <> writes:
> > 
> >> For the few functions that come only in 64-bit off_t flavors,
> >> document their APIs as using off_t instead of off64_t,
> >> and say also that code should #define _FILE_OFFSET_BITS 64.
> >> This documents what user code is (and should be) doing anyway,
> >> if it needs to work on traditional x86 and ARM Linux.
> > 
> > LGTM and thank you Paul.
> > 
> > I haven't checked for other prototypes/examples which need
> > changing.
> Thanks, I'm going to apply the patch.  Can you please confirm if I'm
> correct in adding the following tags?
>     Reported-by: Rich Felker <>
>     Fixes: 9bebb17e5b57 ("splice.2: Use 'off64_t' instead of 'loff_t'")
>     Fixes: 76c5631fb442 ("copy_file_range.2: Document glibc wrapper instead of kernel syscall")
>     Fixes: 5cabfa06b407 ("man-pages 1.68")
>     Fixes: 3ca974e3988a ("New page for sync_file_range(2), new in kernel 2.6.17.")
>     Fixes: 9bebb17e5b57 ("sync_file_range.2: Document the architecture-specific sync_file_range2() system call")
>     Fixes: 79bf8cdcf36a ("Document fopencookie(3), a library function that allows custom implementation of a stdio stream.")
>     Signed-off-by: Paul Eggert <>
>     Reviewed-by: Sam James <>
>     Cc: Jonathan Wakely <>
>     Cc: Szabolcs Nagy <>
>     Cc: Jakub Wilk <>
>     Cc: A. Wilcox <>
>     Signed-off-by: Alejandro Colomar <>
> BTW, Rich, please note the commits that this fixes: most of them are
> the initial commit that adds a page, which means that the function
> had always been documented with off64_t in the "spec".  Only splice(2)
> and copy_file_range(2) have been adjusted afterwards, and in a manner
> to be consistent with the rest of the pages, so I can only conclude
> that we didn't break the spec, but rather fixed it.
> Nevertheless, I'm sorry that it caused any problems to musl, and I'm
> happy that you reported them and so we can now improve the pages.

While I like off_t, I am still unhappy that this seems to have been a
unilateral action from documentation side without even hearing input
from any major implementors other than myself. Is "you can't use these
interfaces without -D_FILE_OFFSET_BITS=64" an acceptable outcome to
the glibc folks?


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.