[pylucene-dev] Re: [Bug 11492] JCC uses wrong type for pointers

[Andi Vajda]

On Wed, 28 Nov 2007, bug-comment at osafoundation.org 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..