[Guido, on the list(xrange(maxint // 4)) test]
> That's strange -- that test is specifically designed to fail before it
> ever gets to allocating memory. Can you track this down with a
> debugger?
[Martin]
> Notice that this test does not strictly achieve that:
This is true, although I'd say it plain doesn't achieve that, and leave
"strictly" out of it.
> with a four-byte pointer, you attempt to allocate 0x20000000L items (due
> to roundupsize), which is small enough to try a realloc. In turn, it
> tries to allocate 0x80000000L bytes, i.e. 2GB. On a 32-bit machine, it
> is possible to allocate that much memory.
Depending on platform, of course. Under MSVC6, it does call the platform
realloc(), and it's the latter that returns a NULL pointer (the max you can
alloc under Win32 is 0x7ffdefff).
If we changed the test to use maxint // 2 instead, it would (just barely)
trigger the
_new_size <= ((~(size_t)0) / sizeof(type))
test in NRESIZE instead, and keep the platform realloc() out of it.
Good enough?
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