I ran "autoreconf" to update configure and related files.

@pablogsal Why are you using _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH in os_copy_file_range_impl()? Those macros are completely useless there. They are only needed on MSVC.

@giampaolo Could you make another review of this PR?

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@gpshead Fixed in 9f4d18c.

Thanks for taking a look :)

The rebase was a bit complex and I missed that when regenerating the autotools files.

Overall this looks good to me, especially for beta1.

From past experience, an issue that might come up in the future: A build could be done on a system where copy_file_range is defined as far as configure is concerned, yet isn't actually available or supported on the system the binary gets run on (old kernel, etc). This usually results in an EINVAL OSError. not a problem for us, but sometimes our buildbots are weird. So don't be surprised if we need to go adjust conditions under which the tests run vs get skipped in the future.

From past experience, an issue that might come up in the future: A build could be done on a system where copy_file_range is defined as far as configure is concerned, yet isn't actually available or supported on the system the binary gets run on (old kernel, etc).

I am handling that here:

https://github.com/python/cpython/pull/7255/files#diff-af1a300489e3d8b6bdde858f37fc541eR298

Do you think is enough or more checks should be done around that aspect?

I have exposed this syscall in a project I'm working on and I took this route instead:

#undef HAVE_COPY_FILE_RANGE

#if defined(__linux__)
    #if defined(__GLIBC_PREREQ)
        #if __GLIBC_PREREQ(2, 27)
            #include <unistd.h>
            #define HAVE_COPY_FILE_RANGE
        #endif
    #endif
#endif


#ifdef HAVE_COPY_FILE_RANGE
// function definition
#endif

I am not sure but I suspect the above could avoid the ENOSYS scenario. Thoughts?

I am not sure but I suspect the above could avoid the ENOSYS scenario. Thoughts?

I am going to land this PR to make sure we do not miss feature freeze. I will leave the issue open so we can discuss how to handle different glibc versions.

Thank you, everyone, for the thorough review! 🎉

Why you mind to mention the new function at https://docs.python.org/dev/whatsnew/3.8.html#os ?