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