[Python-Dev] PEP 296 - The Buffer Problem

[Thomas Heller]

From: "Tim Peters" <tim@zope.com>
> [Thomas Heller]
> > So isn't the conclusion that sizeof(size_t) == sizeof(void *) on
> > any platform,
> 
> Last I knew, there were dozens of platforms besides Linux and Windows
> <wink>.  Like I said, no relationship is defined here.  C99 standardizes a
> uintptr_t typedef for an unsigned integer type with "enough bits" so that
> 
>     (void*)(uintptr_t)p == p
> 
> for any legit pointer p of type void*, but only standarizes its name, not
> its existence (a conforming implementation isn't required to supply a
> typedef with this name).  Such a type *is* required to compile Python,
> though, and pyport.h defines our own Py_uintptr_t (as a synonym for the
> platform uintptr_t if it exists, else to the smallest integer type it can
> find that looks big enough, else a compile-time #error).
> 
> > and so the index should be of type size_t instead of
> > int, long, or LONG_LONG (aka __int64 in some places)?
> 
> Try to spell out exactly what it is you think this index should be capable
> of representing; e.g., what's your most extreme use case?
> 
*I* have no use for this at the moment.
I was just trying to understand the (let's call it) large
byte-array support in Scott's proposal on 64-bit platforms,
and how to program portably on 64-bit and 32-bit platforms.

Assuming we have a large enough byte array
  unsigned char *ptr;
and want to use it in C, for example get a certain byte:

  unsigned char *mybyte = ptr[my_index];

What should the type of my_index be? IIRC, Scott proposed LONG_LONG,
but wouldn't this be a paint on 32-bit platforms?

Thomas