r43041 - python/trunk/Modules/_ctypes/cfield.c
(Regarding changes caused by ssize_t0 Martin v. Löwis wrote:
It is possible to look at the changed APIs, see
I think the problem is more with APIs that are not part of the sequence page. For instance, in http://mail.python.org/pipermail/python-dev/2006-March/062679.html M.-A. Lemburg mentioned PyAPI_FUNC(int) PyDict_Next( PyObject *mp, Py_ssize_t *pos, PyObject **key, PyObject **value); PyDict_Next isn't on the sequence page, but if you call it, it could write a Py_ssize_t into pos, even though your pointer is only large enough for an int. To do things correctly, you really have to change your call to the new version (and add the #ifdef) #if PY_VERSION_HEX < 0x02050000 typedef int Py_ssize_t; #endif You can downcast if you aren't ready to support 64-bits, but ... setting up a possible buffer overflow is a bit worse than simply not supporting. -jJ
Jim Jewett wrote:
It is possible to look at the changed APIs, see
I think the problem is more with APIs that are not part of the sequence page. For instance, in
http://mail.python.org/pipermail/python-dev/2006-March/062679.html
M.-A. Lemburg mentioned
PyAPI_FUNC(int) PyDict_Next( PyObject *mp, Py_ssize_t *pos, PyObject **key, PyObject **value);
PyDict_Next isn't on the sequence page, but if you call it, it could write a Py_ssize_t into pos, even though your pointer is only large enough for an int.
I gave the sequence page just as an example. The new signature of PyDict_Next is also documented, see http://docs.python.org/dev/api/dictObjects.html#l2h-629
To do things correctly, you really have to change your call to the new version (and add the #ifdef)
#if PY_VERSION_HEX < 0x02050000 typedef int Py_ssize_t; #endif
You can downcast if you aren't ready to support 64-bits, but ... setting up a possible buffer overflow is a bit worse than simply not supporting.
Sure. In that case, the compiler will give you a compiler warning, on a 64-bit system. You certainly should react to that warning. I personally doubt that somebody would go through the list of the 100-something APIs that changed, memorize them, and then go to his source code, to find out what to change; I know that I don't work that way. That said, if somebody things it is worthwhile to create such a list: contributions are welcome. Regards, Martin
On 3/20/06, "Martin v. Löwis"
Jim Jewett wrote:
To do things correctly, you really have to change your call to the new version (and add the #ifdef)
#if PY_VERSION_HEX < 0x02050000 typedef int Py_ssize_t; #endif
You can downcast if you aren't ready to support 64-bits, but ... setting up a possible buffer overflow is a bit worse than simply not supporting.
Sure. In that case, the compiler will give you a compiler warning, on a 64-bit system. You certainly should react to that warning.
The person compiling on a 64-bit system may not be the developer. The buildbot was started in part because the Windows build didn't work -- many developers didn't have a windows environment to test with. This change will put 64 bit systems in the same awkward position -- they need different code, which many developers can't really test properly.
I personally doubt that somebody would go through the list of the 100-something APIs that changed, memorize them, and then go to his source code, to find out what to change;
Agreed; they would be more likely to run a grep for a one-time conversion. Catching the error as it creeps back in later would be ... something people learn the hard way. But not having that list for a grep makes the situation even worse. -jJ
participants (2)
-
"Martin v. Löwis" -
Jim Jewett