On Fri, Apr 29, 2016 at 12:18:46PM -0400, Random832 wrote:
> On Fri, Apr 29, 2016, at 10:45, Marcos Dione wrote:
> > One possible solution hat was suggested to me in the #python IRC
> > channel was to use that, then test if the resulting value is negative,
> > and adjust accordingly, but I wonder if there is a cleaner, more general
> > solution (for instance, what if the type was something else, like loff_t,
> > although for that one in particular there *is* a convertion
> > function/macro).
> In principle, you could just use PyLong_AsUnsignedLong (or LongLong),
> and raise OverflowError manually if the value happens to be out of
> size_t's range. (99% sure that on every linux platform unsigned long is
> the same size as size_t.
> But it's not like it'd be the first function in OS to call a system call
> that takes a size_t. Read just uses Py_ssize_t. Write uses the buffer
> protocol, which uses Py_ssize_t. How concerned are you really about the
> lost range here? What does the system call return (its return type is
> ssize_t) if it writes more than SSIZE_MAX bytes? (This shouldn't be hard
> to test, just try copying a >2GB file on a 32-bit system)
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.
> I'm more curious about what your calling convention is going to be for
> off_in and off_out. I can't think of any other interfaces that have
> optional output parameters. Python functions generally deal with output
> parameters in the underlying C function (there are a few examples in
> math) by returning a tuple.
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.