Is this a microsoft VC++ 2010 compiler bug of "new auto(enum_type)"

Question

Enviroment: Microsoft Visual Studio 2010 with SP1 Preminum(10.0.40219.1 SP1Rel), Windows XP SP3

VC10 compiler support auto keyword, but the deduced type related information seems not always correct for enumeration.

example:

#include <type_traits>

enum fruit_t
{
    apple = 100,
    banana = 200,
};

int main()
{
    const auto pa = new auto(banana);
    const auto pb = new fruit_t(banana);
    static_assert(std::is_same<decltype(pa), decltype(pb)>::value, "not same!");
    delete pb;
    delete pa;
}

The code above should have no compiler-time error or runtime error. But what suprising me is that, it compiles ok without any error or warning but, does not run correctly. The debugger tells after exit the main function:

HEAP CORRUPTION DETECTED: after %hs block (#55) at 0x00034878. CRT detected that the application wrote to memory after end of heap buffer.

so I guess that the compiler may have bug in "auto" type deduction. Assembler window below shows that, the requested memeory size in the first "operator new" call is 1 byte, while the second "operator new" 4 bytes. It suggests that the compiler has made a big mistake on the size of deduced type.

Did you think this is a compiler bug? And is there any bug fixes from Microsoft?

int main()
{
004113C0  push        ebp  
004113C1  mov         ebp,esp  
004113C3  sub         esp,10Ch  
004113C9  push        ebx  
004113CA  push        esi  
004113CB  push        edi  
004113CC  lea         edi,[ebp-10Ch]  
004113D2  mov         ecx,43h  
004113D7  mov         eax,0CCCCCCCCh  
004113DC  rep stos    dword ptr es:[edi]  
    const auto pa = new auto(banana);
004113DE  push        1  
004113E0  call        operator new (411181h)  
004113E5  add         esp,4  
004113E8  mov         dword ptr [ebp-104h],eax  
004113EE  cmp         dword ptr [ebp-104h],0  
004113F5  je          main+51h (411411h)  
004113F7  mov         eax,dword ptr [ebp-104h]  
004113FD  mov         dword ptr [eax],0C8h  
00411403  mov         ecx,dword ptr [ebp-104h]  
00411409  mov         dword ptr [ebp-10Ch],ecx  
0041140F  jmp         main+5Bh (41141Bh)  
00411411  mov         dword ptr [ebp-10Ch],0  
0041141B  mov         edx,dword ptr [ebp-10Ch]  
00411421  mov         dword ptr [pa],edx  
    const auto pb = new fruit_t(banana);
00411424  push        4  
00411426  call        operator new (411181h)  
0041142B  add         esp,4  
0041142E  mov         dword ptr [ebp-0F8h],eax  
00411434  cmp         dword ptr [ebp-0F8h],0  
0041143B  je          main+97h (411457h)  
0041143D  mov         eax,dword ptr [ebp-0F8h]  
00411443  mov         dword ptr [eax],0C8h  
00411449  mov         ecx,dword ptr [ebp-0F8h]  
0041144F  mov         dword ptr [ebp-10Ch],ecx  
00411455  jmp         main+0A1h (411461h)  
00411457  mov         dword ptr [ebp-10Ch],0  
00411461  mov         edx,dword ptr [ebp-10Ch]  
00411467  mov         dword ptr [pb],edx  
    static_assert(std::is_same<decltype(pa), decltype(pb)>::value, "not same!");
    delete pb;
0041146A  mov         eax,dword ptr [pb]  
0041146D  mov         dword ptr [ebp-0ECh],eax  
00411473  mov         ecx,dword ptr [ebp-0ECh]  
00411479  push        ecx  
0041147A  call        operator delete (411087h)  
0041147F  add         esp,4  
    delete pa;
00411482  mov         eax,dword ptr [pa]  
00411485  mov         dword ptr [ebp-0E0h],eax  
0041148B  mov         ecx,dword ptr [ebp-0E0h]  
00411491  push        ecx  
00411492  call        operator delete (411087h)  
00411497  add         esp,4  
}

Answer 1

Yes, I think it's a VS2010 bug. Running the same as you (or at least very similar) with XP SP3 (32-bit) and VS2010 SP1, I get the exact same error. It looks to be specific to enums, as trying it with classes showed everything working properly. I also tried adding another fruit item to the enum, with a value of 100000 just to make sure it wasn't something silly like your enum having all values below 255. Same result.

I did a quick search at Microsoft Connect, and I do not see a bug report for this, so I recommend that you enter one. That is the best way to make sure Microsoft knows and possibly get it fixed.