[Python-Dev] PEP 296 - The Buffer Problem
Wed, 24 Jul 2002 16:22:54 -0700 (PDT)
--- Tim Peters <email@example.com> wrote:
> > 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.
Yep. I was trying to contrast that on most platforms LONG_LONG is an alias
for "long long", but on Windows (32 or 64) it's going to be an __int64.
> > 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.
> example, Python manages to support 64-bit "subscripts" to f.seek() on the
> major 32-bit boxes right now.
I should have been more clear. I was referring specifically to working
datum = *(pointer + offset);
datum = pointer[offset];
Just so there is no confusion, you aren't suggesting that the bytes PEP
should provide a mechanism to support chunks of memory larger than 4 Gigs
on 32 bit platforms right?
I think the bytes object could be a part of the solution to that problem,
at least I know how I would do that under Win32, but I'd rather not kluge
up the interface to the bytes object to support it directly.
Do You Yahoo!?
Yahoo! Health - Feel better, live better