Re: [musl] Re: [libc-coord] [PATCH v4] off64_t: prefer off_t for splice, etc.

[Rich Felker <dalias@libc.org>]

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 <eggert@cs.ucla.edu> 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 <dalias@libc.org>
>     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 <eggert@cs.ucla.edu>
>     Reviewed-by: Sam James <sam@gentoo.org>
>     Cc: Jonathan Wakely <jwakely@redhat.com>
>     Cc: Szabolcs Nagy <nsz@port70.net>
>     Cc: Jakub Wilk <jwilk@jwilk.net>
>     Cc: A. Wilcox <AWilcox@wilcox-tech.com>
>     Signed-off-by: Alejandro Colomar <alx@kernel.org>
> 
> 
> 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?

Rich