RFC: should copy_file_range(2) use size_t or off_t for length argument

[Rick Macklem]

Hi,

r350315 implemented a Linux compatible copy_file_range(2) syscall.
Since Linux used a length argument of size_t and a return argument
type of ssize_t, I did the same.

Kostik has suggested that making these off_t would allow a full 64bit
copy be done on 32bit arches.
Here is the snippet of discussion we have had:
Kostik Belousov wrote:
> >Kostik Belousov wrote:
>> >I sat to write the compat32 shims, and only then noted that len has size_t
>> >type.  Why is it size_t and not off_t ?
> I wrote:
>> Well, that's what Linux did.
>> 
>> Also, since it returns ssize_t, it can't do more than SSIZE_MAX
>> (generally 1/2 of SIZE_T_MAX). Returning ssize_t is also what Linux
>> does and is consistent with read(2)/write(2).
>
>If changing the length argument type to off_t, it is reasonable to change
>the return type to off_t as well.  We already have the lseek(2) syscall that
>requires two return registers on 32bit.
>
>Note that it is reasonable for read(2) to take length as size_t-typed
>parameter, because size_t is the type for object sizes. There is no
>object in user address space for copy_file_range(2) API, so potentially
>wider off_t is acceptable and is in fact useful there. It is useful on
>32bit machines where FreeBSD size_t is 32bit, while off_t is 64bit.

So, what do others think?
(My only concern w.r.t. changing the arguments to off_t is Linux compatibility.)

rick