[Python-Dev] PEP 296 - The Buffer Problem

[Tim Peters]

[Scott Gilbert]
> At the moment, the only 64 bit platform that I have easy access to is
> Tru64/Alpha.  That version of malloc takes a size_t which is a 64 bit
> quantity.
>
> I believe most semi-sane platforms will use a size_t as argument for
> malloc,

That much is required by the C standard, so you can rely on it.

> and I believe most semi-sane platforms will have a size_t that is
> the same number of bits as a pointer for that platform.

The std is silent on this; it's true on 64-bit Linux and Win64, so "good
enough".

>> Can you index these byte arrays by longs?

> You could index it via a long, but using a LONG_LONG is safer.  My
> understanding is that on Win64 a long will only be 32 bits even though
> void* is 64 bits.

Right.

> So for that platform, LONG_LONG will be a typedef for __int64 which is 64
> bits.

Also on Win32:  LONG_LONG is a 64-bit integral type on Win32 and Win64.

> None of this matters for 32 bit platforms.

?  Win32 has always supported "large files" and "large mmaps" (where large
means 64-bit capacity), and most 32-bit flavors of Unix do too.  It's a
x-platform mess, though.

> All 32 bit platforms that I know of have sizeof(int) == sizeof(long) ==
> sizeof(void*) == 4.

Same here.

> So even if you wanted to subscript with a long or LONG_LONG, the pointer
> could only point to something about 2 Gigs (31 bits) in size.

That depends on how it's implemented; on a 32-bit box, supporting a
LONG_LONG subscript may require some real pain, but isn't impossible.  For
example, Python manages to support 64-bit "subscripts" to f.seek() on the
major 32-bit boxes right now.