M.-A. Lemburg wrote: > What if x64 has a 64-bit value ? How do you catch > and process the truncation error ?
We were *both* discussing a scenario where no sizes exceed 2**31, right? Under such a scenario, this just won't happen. OTOH, if you were discussing a scenario where sizes might exceed 2**31, then I don't see why you are worried about Py_ssize_t* parameters alone: Even PyString_Size() might (of course!) return a value > 2**31 - so it is not just output parameters, but also return values. For more information, please read "Conversion guidelines" in http://www.python.org/peps/pep-0353.html >>That is not necessary. Can you give in example of a module >>where you think it is necessary? > > > If you want to port the extension to Py_ssize_t, this > is essentially the case. > > You might want to take the unicodeobject.c file as > example. unicodeobject.c is not an extension. We were discussing existing extension modules. > We could use the type flags for these. much like we > do for the new style numbers. Would you like to write a specification for that? > If you don't like the macro approach, why not simply > leave the two separate sets of APIs visible. To simplify the porting. > All Py_ssize_t aware and compatible extensions > would use the new APIs instead. The old-style APIs > should then take care of the proper down-casting and > error reporting. That is not possible. Some API does not support error reporting (like PyString_Size()). So callers don't expect it to fail. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
