[Python-Dev] Convert int() to size_t in Python/C

Martin Panter vadmium+py at gmail.com
Fri Apr 29 19:42:03 EDT 2016

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).

More information about the Python-Dev mailing list