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) 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. Maybe return a tuple (returned value, off_in, off_out), where None corresponds to the input parameter having been NULL (and passing None in makes it use NULL)? _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
