[Python-Dev] sizeof(long) != sizeof(void*)

[Tim Peters]

[Martin]
> ...
> I feel this is deeper: Should there be a guarantee that the type used
> to represent <type 'integer'> is large enough to hold a void*, or not?

The confusion over what you mean still persists for me.  In the Python I use
<wink>, there is no type that identifies itself as <type 'integer'>.
There's a type that identifies itself as <type 'int'>, and another as <type
'long'>.  When the Language Reference Manual uses the word "integer", it
generally means the union of those two.

It's certainly not intended that objects of <type 'int'> can always hold a
casted void*.  It certainly is intended that objects of <type 'long'> can
always hold a casted void*.  So it's intended that a Python integer be able
to hold a casted void*, but "integer" doesn't take a stand on whether the
concrete type is Python int or Python long.  After int/long unification is
complete, the distinction will be even more a case of academic irrelevance.

> You seem to think that Python should make no such guarantee,

Definitely yes, or definitely no, depending on what you mean by "integer".
I explained what I mean above.

> which would then indicate that three of the four failing tests are broken
> (I'm uncertain about test_queue at the moment).

It's easy to believe that tests have broken, since (a) AFAIK nobody runs the
tests on Win64, and (b) Win64 may well be the only platform around where
sizeof(void*) > sizeof(long) in C (meaning that a casted void* can't fit in
a Python int -- although it can fit in a Python integer, and
PyLong_FromVoidPtr already knows how to deal with this).