From f564bb3cca39370d2b0ee850ddf913ffc4b1b446 Mon Sep 17 00:00:00 2001 From: Elliott Hughes Date: Mon, 13 Jun 2022 17:19:31 -0700 Subject: [PATCH] Avoid copy_file_range(2) on Android. Strictly we could use it if the target API level is high enough, but that would mean that you couldn't safely run the resulting binary on an older Android release, and anecdotally I don't think people are that careful. The obvious alternative would be to install a signal handler for SIGSYS so we can probe for copy_file_range(2) at runtime rather than compile time, but it's not obvious to me that it matters enough? --- lib/portability.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/portability.c b/lib/portability.c index 89ee78e9..e60e525e 100644 --- a/lib/portability.c +++ b/lib/portability.c @@ -639,7 +639,9 @@ long long sendfile_len(int in, int out, long long bytes, long long *consumed) if (try_cfr) { if (bytes<0 || bytes>(1<<30)) len = (1<<30); // glibc added this constant in git at the end of 2017, shipped 2018-02. -#if defined (__NR_copy_file_range) + // Android's had the constant for years, but you'll get SIGSYS if you use + // this system call before Android U (2023's release). +#if defined(__NR_copy_file_range) && !defined(__ANDROID__) len = syscall(__NR_copy_file_range, in, 0, out, 0, len, 0); #else errno = EINVAL; -- 2.39.2