
On Fri, Apr 29, 2016 at 12:18:46PM -0400, Random832 wrote:
It's a very good point, but I don't have any 32 bits systems around with a kernel-4.5. I'll try to figure it out and/or ask in the kernel ML.
These are not output parameters, even if they're pointers. they'r using the NULL pointer to signal that the current offsets should not be touched, to differentiate from a offset of 0. Something that in Python we would use None.

On Fri, Apr 29, 2016, at 14:11, Marcos Dione wrote:
That's not actually true according to the documentation. (And if it were, they could simply use -1 rather than a null pointer) If you pass a null pointer in, the file's offset is used and *is* updated, same as if you used an ordinary read/write call. If you pass a value in, that value is used *and updated* (which makes it an output parameter) and the file's offset is left alone. Documentation below, I've >>>highlighted<<< the part that shows they are used as output parameters: The following semantics apply for off_in, and similar statements apply to off_out: * If off_in is NULL, then bytes are read from fd_in starting from the file offset, and the file offset is adjusted by the number of bytes copied. * If off_in is not NULL, then off_in must point to a buffer that specifies the starting offset where bytes from fd_in will be read. The file offset of fd_in is not changed, >>>but off_in is adjusted appropriately.<<<

On 29 April 2016 at 18:25, Random832 <random832@fastmail.com> wrote:
Linux’s sendfile() syscall takes a similar offset parameter that may be updated, but Python’s os.sendfile() wrapper does not return the updated offset. Do you think we need to return the updated offsets for copy_file_range()?

On 29 April 2016 at 18:11, Marcos Dione <mdione@grulic.org.ar> wrote:
I would probably just use Py_ssize_t, since that is what the return value is. Otherwise, a large positive count input could return a negative value, which would be inconsistent, and could be mistaken as an error.
It's a very good point, but I don't have any 32 bits systems around with a kernel-4.5. I'll try to figure it out and/or ask in the kernel ML.
Maybe you can compile a 32-bit program and run it on a 64-bit computer (gcc -m32).

On Fri, Apr 29, 2016, at 14:11, Marcos Dione wrote:
That's not actually true according to the documentation. (And if it were, they could simply use -1 rather than a null pointer) If you pass a null pointer in, the file's offset is used and *is* updated, same as if you used an ordinary read/write call. If you pass a value in, that value is used *and updated* (which makes it an output parameter) and the file's offset is left alone. Documentation below, I've >>>highlighted<<< the part that shows they are used as output parameters: The following semantics apply for off_in, and similar statements apply to off_out: * If off_in is NULL, then bytes are read from fd_in starting from the file offset, and the file offset is adjusted by the number of bytes copied. * If off_in is not NULL, then off_in must point to a buffer that specifies the starting offset where bytes from fd_in will be read. The file offset of fd_in is not changed, >>>but off_in is adjusted appropriately.<<<

On 29 April 2016 at 18:25, Random832 <random832@fastmail.com> wrote:
Linux’s sendfile() syscall takes a similar offset parameter that may be updated, but Python’s os.sendfile() wrapper does not return the updated offset. Do you think we need to return the updated offsets for copy_file_range()?

On 29 April 2016 at 18:11, Marcos Dione <mdione@grulic.org.ar> wrote:
I would probably just use Py_ssize_t, since that is what the return value is. Otherwise, a large positive count input could return a negative value, which would be inconsistent, and could be mistaken as an error.
It's a very good point, but I don't have any 32 bits systems around with a kernel-4.5. I'll try to figure it out and/or ask in the kernel ML.
Maybe you can compile a 32-bit program and run it on a 64-bit computer (gcc -m32).
participants (3)
-
Marcos Dione
-
Martin Panter
-
Random832