Convert int() to size_t in Python/C
First of all, I'm not subbscribed to the list (too much traffic for me), so please CC: me in any answers if possible. I'm trying to add a new syscall to the os module: https://bugs.python.org/issue26826 One of the few missing parts is to cenvert a parameter, which would be a Python int object using PyArg_ParseTupleAndKeywords() to a size_t variable. For something similar, the 'n' format exists, but that one converts to Py_ssize_t (which is ssize_t, really), but that one is signed. 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). -- (Not so) Random fortune: Premature optimization is the root of all evil. -- Donald Knuth
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)?
On 4/29/2016 10:45 AM, Marcos Dione wrote:
First of all, I'm not subbscribed to the list (too much traffic for me), so please CC: me in any answers if possible.
I am indulging you this once, but the proper solution is to read pydev via the gmane.comp.python.devel mirror at news.gmane.com. You can do so either with a newsreader, part of most mail clients, subscribed to the group, or with a browser pointed at the site. There are multiple problems with CC:. First, the paragraph above may be (properly) snipped from replies, so you will not get replies to replies. Second, 'Reply all' is a nuisance as it takes 'all' too literally. Since I receive via gmane, Thunderbird tries to reply to both gmane and mail.python.org, but the latter is invalid and generates a nuisance email as I am not subscribed. If I were subscribed, sending and posting this twice would also be wrong. Third, and related, CC lists tend to grow. If someone hits 'Reply all' to this message, I will be added to the list, and will received a nuisance duplicate email, unless the person takes the trouble to remove me. (They often do not.) -- Terry Jan Reedy
participants (3)
-
Marcos Dione -
Random832 -
Terry Reedy