On 29 April 2016 at 18:11, Marcos Dione <mdione at grulic.org.ar> wrote: > 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) 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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4