[Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Tue Mar 21 00:24:44 CET 2006
- Previous message: [Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c
- Next message: [Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jim Jewett wrote:
It is possible to look at the changed APIs, see
http://docs.python.org/dev/api/sequence.html 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 PyAPIFUNC(int) PyDictNext( PyObject *mp, Pyssizet *pos, PyObject **key, PyObject **value); PyDictNext isn't on the sequence page, but if you call it, it could write a Pyssizet 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 PYVERSIONHEX < 0x02050000 typedef int Pyssizet; #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
- Previous message: [Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c
- Next message: [Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]