[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190820005635.GC9017@brightrain.aerifal.cx>
Date: Mon, 19 Aug 2019 20:56:35 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add copy_file_range system call
On Mon, Aug 19, 2019 at 11:41:14PM +0000, Árni Dagur wrote:
> This patch was based on commit 53147f9, which added splice and vmsplice.
> ---
> The function signature in the glibc manpage specifies `loff_t` instead
> of `off_t`, for both `copy_file_range` and `splice`. In musl, however,
> the function signature for `splice` specifies `off_t`, so I did the
> same here. I'm not an experienced C programmer, so that may have been
> wrong.
I think this looks ok. Regarding loff_t vs off_t, loff_t is the
kernel's API type for functions that take a 64-bit offset
unconditionally rather than glibc providing 32-bit off_t and 64-bit
off_t versions of them. This is gratuitous for musl where off_t is
always 64-bit. We provide loff_t as a macro that expands to off_t, but
even if it were a typedef the types woule be the same type, so it's
fine to use off_t here, and I think it's the cleanest and most
consistent with what we're doing elsewhere even if it's not textually
the same as the man page.
> include/unistd.h | 1 +
> src/linux/copy_file_range.c | 8 ++++++++
> 2 files changed, 9 insertions(+)
> create mode 100644 src/linux/copy_file_range.c
>
> diff --git a/include/unistd.h b/include/unistd.h
> index 9485da7a..00cc7042 100644
> --- a/include/unistd.h
> +++ b/include/unistd.h
> @@ -188,6 +188,7 @@ char *get_current_dir_name(void);
> int syncfs(int);
> int euidaccess(const char *, int);
> int eaccess(const char *, int);
> +ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags);
> #endif
Is there a reason for the choice to put it in unistd.h? Similar
functions seem to have gone in fcntl.h. unistd.h does not make the
loff_t type available which could be problematic to callers using it,
since they really should (for API compatibility) be declaring the
objects whose addresses they pass as loff_t.
If glibc does it here and exposes loff_t in unistd.h we might need to
consider doing that too with _GNU_SOURCE.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
