[Pyrex] Bug wrt 64-bit and hash()

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> It seems pyrex 0.9.8.5 has a bug with how it handles "hash()". I have
> this code:
> 
> cdef long the_hash
> 
> the_hash = hash(my_object)
> 
> When I look at the source code generated, I see:
> 
> long __pyx_v_the_hash;
> int __pyx_1;
> 
> __pyx_1 = PyObject_Hash(my_object); if (__pyx_1 == -1...)
> __pyx_v_the_hash = __pyx_1;
> 
> The problem is that Pyrex is thinking that 'hash()' returns a 32-bit
> 'int', when it really returns a 64-bit 'long'. Which means that my hash
> values are getting truncated.
> 
> I only noticed because I have other code that grabs the hash directly
> from PyObject_Hash and/or Py_TYPE(obj).tp_hash(obj) which don't truncate
> the value.
> 
> 
> The basic fix seems like it would just be informing Pyrex that
> "PyObject_Hash()" returns a 'long' and not an 'int'. I just checked and
> cython 0.11.3 does use a 'long' temporary variable in this situation.
> 
> John
> =:->


I just wanted to follow up that pyrex 0.9.7.2 also generates a 'long'
for the temporary variable. So this seems to be a regression in 0.9.8.5
vs 0.9.7.2.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrUr4MACgkQJdeBCYSNAAM5KwCg0XnjWlLdhZkrDqHEgVGU1s/B
R+cAoNAuGQPjbVcLuzsuiWEadZc7F7BQ
=dhxC
-----END PGP SIGNATURE-----