On Wed, 28 Nov 2007, [EMAIL PROTECTED] wrote:
Let me disagree with the solution. Even if Py_intptr_t was not available in
Python 2.3.5 (actually it is there, just take a look at pyport.h), a more
standard solution is to use either size_t or its Python equivalent, Py_ssize_t.
There is no pyport.h file in Python 2.3.5 (at least as shipped by Apple with
Leopard) Maybe, it appeared in 2.3.6 ?
You can run into the same problems as before using unsigned long, instead of a
platform defined type (size_t is defined as int in ia32, long in x86_64, long
long for 128bit archs, etc.). Actually it might be preferable to use
Py_uintptr_t, this is what Python 2.3.6 pyport.h says:
/* uintptr_t is the C9X name for an unsigned integral type such that a
* legitimate void* can be cast to uintptr_t and then back to void* again
* without loss of information. Similarly for intptr_t, wrt a signed
* integral type.
*/
If uintptr_t is defined in C, sure, of course I should use it.
I've reopened this bug, but feel free to close it, I won't argue. But, you
might want to take a look at how other Python extensions fixed issues like
this. For example, ZODB had the same problem in Persistent module, and fixed it
using Py_ssize_t
Py_ssize_it isn't available in Python 2.3.5 either.
But, in principle, you're right. Using "unsigned long" is flaky there too.
I'm not particularly happy to be supporting Python 2.3 but some mac users
complain anytime I drop or break support for it. I had to crud up the JCC
source code quite a bit to make it run on Python 2.3 :(
I'm going to try to switch to size_t or uintptr_t if gcc and msvc support
that type without kludges.
No problems with arguing this. I'd like to do what's right without too much
hassle just as well.
Thanks !
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
