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
On 18/12/2017 19:53, Joseph Myers wrote:
> 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.)
>
Agreed, I prefer to 1. since the syscall also shows the same behaviour
with EFBIG.