--- Tim Peters <tim@zope.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.
> For
> 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
with pointers:
datum = *(pointer + offset);
or:
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.
Cheers,
-Scott
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4