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
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