On Saturday 10 March 2007, Greg Ewing wrote: > I'm wondering whether something here should really be using > uintptr_t instead of intptr_t. Does it work if you use > > ctypedef unsigned long intptr_t > > instead?
Yeah, I think that this is the right thing to do - I have realized this just after sending my mail and going to bed yesterday. The problem is that Python 2.4 and older were sometimes returning longs but signed when calling id() (the problem occurs in models/material.pyx:95) , so negative numbers were possible. The only change was that now id() returns an always positive (unsigned long) in Python 2.5 and you cannot store an unsigned long needing 32 bits into a signed long where you have only 31 bits available (the last one is the sign) An easy way to see this change is to call id(object()) in Python 2.4 and 2.5. 2.4 will often return a negative value, 2.5 always positive. I will try to change this to unsigned long and recompile, let's see what happens. Long long obviously "fixed" it, because instead of adding only the one "missing" bit it added a whole 32 bit word. Jan -- Jan Ciger GPG public key: http://www.keyserver.net/
pgpLSBBwdzBoS.pgp
Description: PGP signature
_______________________________________________ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
