This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] copy_file_range: New function to copy file data
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>
- Date: Mon, 18 Dec 2017 21:53:56 +0000
- Subject: Re: [PATCH] copy_file_range: New function to copy file data
- Authentication-results: sourceware.org; auth=none
- References: <20171117145604.655D24469B999@oldenburg.str.redhat.com> <16de12bf-eab1-b69c-cd58-a6dd24ad409f@redhat.com> <eeee1a5f-63c5-4379-1fd4-7f0319d28cd4@linaro.org>
On Mon, 18 Dec 2017, Adhemerval Zanella wrote:
> Will again return EFBIG. We have some options as 1. handle EFBIG
> as an expected retuned error, 2. do not declare copy_file_range for
> !__USE_FILE_OFFSET64, 3. add a dummy implementation for non-LFS
> (which return ENOSYS).
Since the default on all platforms, even those with 64-bit off_t
unconditionally, is !__USE_FILE_OFFSET64, I don't think 2. is a good
option; it would gratuitously result in the interface being undeclared on
64-bit platforms when _FILE_OFFSET_BITS is not defined.
(Even on 64-bit platforms, _FILE_OFFSET_BITS=64 results in some changes to
C++ name mangling, as discussed in bug 15766, and breaks namespace rules,
bug 14106; on mips64, it also changes struct stat layout. So, while I
think we should move to _FILE_OFFSET_BITS=64 by default on all platforms,
bug 13047, it's not a completely API-compatible change anywhere, and
fixing namespace issues would be desirable before making such a change.)
--
Joseph S. Myers
joseph@codesourcery.com