[Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c (original) (raw)
Jim Jewett jimjjewett at gmail.com
Tue Mar 21 05:19:03 CET 2006
- Previous message: [Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c
- Next message: [Python-Dev] Expose the array interface in Python 2.5?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/20/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
Jim Jewett wrote:
> 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.
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
- Previous message: [Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c
- Next message: [Python-Dev] Expose the array interface in Python 2.5?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]