This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]