freebsd32 shims for copy_file_range(2)

[kib]

Test Plan

Rick, could you, please, provide me with the test program you used for the syscall check ?

[rmacklem]

I don't really know anything about this, but it looks fine to me.
The only change is uint32_t replaces size_t, which makes sense to 32bits.
(I'm guessing this is only used for amd64, where "int" and "unsigned int"
remain 32bits.)

Hopefully brooks can review this, but if not, I'll click reviewed in a few days.

[brooks]

Why is a shim required? All arguments are extended to 64-bits as part of the combat layer. There would be an issue if len were an off_t, but it's a size_t. The only pointers point to off_t's which are always 64-bit and thus require no special handling.

[kib]

In D21092#458069, @brooks wrote:

Why is a shim required? All arguments are extended to 64-bits as part of the combat layer. There would be an issue if len were an off_t, but it's a size_t. The only pointers point to off_t's which are always 64-bit and thus require no special handling.

Yes, it started with len having off_t, see some discussion on fs@. I am on fence there, I can drop the shim and change STD to NOPROTO, of course.

[kib]

Drop shims.

[brooks]

LGTM