64 bit large mallocs-Collection of common programming errors
Here’s an official source that states the maximum request size of the heap is defined by your linked CRT library (aside from your previous code having integer overflows going to 0 which is why you didn’t get NULL back) (_HEAP_MAXREQ).
http://msdn.microsoft.com/en-us/library/6ewkz86d.aspx
Check out my answer here for large windows allocations, I include a reference to a MS paper on Vista/2008 memory model advancements.
In short, the stock CRT does not support, even for a native 64 bit process any heap size larger than 4gb. You have to use VirtualAlloc* or CreateFileMapping or some other analogues.
Oh I also noticed you are claiming that your larger allocations are actually succeeding, this is actually incorrect, you are mis-interpreting the malloc(0x200000000); (that’s 8gb in hex), what is happening is you are requesting a 0 byte allocation due to a cast or some other effect of your test harness, you are most definitely not observing any thing larger than a 0xfffff000 bytes heap being committed, it is simply you are seeing integer overflows down casting.
WORD TO THE WYSE or * TIPS TO SAVE YOUR HEAP SANITY*
THE ONLY WAY TO ALLOCATE MEMORY WITH MALLOC (OR ANY OTHER DYNAMIC REQUEST)
void *foo = malloc(SIZE);
THE VALUE OF A DYNAMIC MEMORY REQUEST MUST NEVER (I CAN NOT STRESS THAT ENOUGH) BE CALCULATED WITHIN THE “()” PAREN’S OF THE REQUEST
mytype *foo = (mytype *) malloc(sizeof(mytype) * 2);
The danger is that an integer overflow will occur.
It is always a coding ERROR to perform arithmetic at the time of the call, you MUST ALWAYS calculate the TOTAL SUM of data to be requested before the statement which evaluates the request.
Why is it so bad? We know this is a mistake, because the point at which a request is made for dynamic resources, there must be a point in the future where we will use this resource.
To use what we have requested we must know how large it is ? (e.g. the array count, the type size, etc..).
This would mean, if we ever see any arithmetic at all, inside the () of a resource request, it is an error as we MUST duplicate that code again in order to use that data appropriately.