Re: Bug wrt 64-bit and hash()

-----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 =3D hash(my_object)
> =

> When I look at the source code generated, I see:
> =

> long __pyx_v_the_hash;
> int __pyx_1;
> =

> __pyx_1 =3D PyObject_Hash(my_object); if (__pyx_1 =3D=3D -1...)
> __pyx_v_the_hash =3D __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
> =3D:->


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
=3D:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrUr4MACgkQJdeBCYSNAAM5KwCg0XnjWlLdhZkrDqHEgVGU1s/B
R+cAoNAuGQPjbVcLuzsuiWEadZc7F7BQ
=3DdhxC
-----END PGP SIGNATURE-----