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?

On 07/30/2016 07:00 AM, 岩倉 澪 wrote:
>         auto mem = malloc(2^^31);

2^^31 is negative. 2^^31-1 is the maximum positive value of an int, so 2^^31 wraps around to int.min.

Try 2u^^31.

On Saturday, 30 July 2016 at 05:21:26 UTC, ag0aep6g wrote:
> On 07/30/2016 07:00 AM, 岩倉 澪 wrote:
>>         auto mem = malloc(2^^31);
>
> 2^^31 is negative. 2^^31-1 is the maximum positive value of an int, so 2^^31 wraps around to int.min.
>
> Try 2u^^31.

bah, I'm an idiot! CASE CLOSED. Thanks for the help :P