The Mystery of the Misbehaved Malloc

[岩倉 澪 via Digitalmars-d-learn]

So I ran into a problem earlier - trying to allocate 2GB or more 
on Windows would fail even if there was enough room. Mentioned it 
in the D irc channel and a few fine folks pointed out that 
Windows only allows 2GB for 32-bit applications unless you pass a 
special flag which may or may not be a good idea.

I think to myself, "Easy solution, I'll just compile as 64-bit!"

But alas, my 64-bit executable suffers the same problem.

I boiled it down to a simple test:

     void main()
     {
         import core.stdc.stdlib : malloc;
         auto mem = malloc(2^^31);
         assert(mem);
         import core.stdc.stdio : getchar;
         getchar();
     }

I wrote this test with the C functions so that I can do a direct 
comparison with a C program compiled with VS 2015:

     #include <assert.h>
     #include <math.h>
     #include <stdio.h>
     #include <stdlib.h>
     int main(int argc, char *argv[])
     {
         void *ptr = malloc((size_t)pow(2, 31));
         assert(ptr);
         getchar();
         return 0;
     }

I compile the D test with: `ldc2 -m64 -test.d`
I compile the C test with: `CL test.c`

`file` reports "PE32+ executable (console) x86-64, for MS 
Windows" for both executables.

When the C executable runs, I see the allocation under "commit 
change" in the Resource Monitor. When the D executable runs, the 
assertion fails!

The D program is able to allocate up to 2^31 - 1 before failing. 
And yes, I do have enough available memory to make a larger 
allocation.

Can you help me solve this mystery?