2012-06-29 10 views
6

Enviroment: Microsoft Visual Studio 2010 z dodatkiem SP1 Preminum (10.0.40219.1 SP1Rel), Windows XP SP3Czy to Microsoft VC++ 2010 kompilator bug "nowe auto (enum_type)"

VC10 kompilatora wsparcie auto słów kluczowych, ale wydedukowane informacje związane z typem nie zawsze są poprawne dla wyliczenia.

przykład:

#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; 
} 

Powyższy kod powinien mieć żadnego błędu kompilatora lub błąd w czasie wykonywania. Ale co mnie zaskakuje to, że kompiluje ok bez żadnego błędu lub ostrzeżenia, ale nie działa poprawnie. Debugger informuje po wyjściu z głównej funkcji:

WYKRYTO KORUPĘ WYKRYWALIZOWANĄ: po% hs (# 55) przy 0x00034878. CRT wykrył, że aplikacja zapisała do pamięci po końcu bufora sterty.

więc domyślam się, że kompilator może mieć błąd w dedukcji typu "auto". Okno asemblera poniżej pokazuje, że żądany rozmiar pamięci w pierwszym wywołaniu "operator new" wynosi 1 bajt, a drugi "operator new" 4 bajty. Sugeruje to, że kompilator popełnił duży błąd w rozmiarze wyprowadzonego typu.

Czy uważasz, że jest to błąd kompilatora? Czy są jakieś poprawki błędów od Microsoftu?

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 
} 
+1

W debugerze jaki jest typ "pa"? – RedX

+0

debugger pokazuje: banana 0x000000c8 int; pa 0x000329d8 fruit_t * const; pb 0x00032a18 fruit_t * const. Niestety, pokazuje to, że "banan" jest typu "int" (nie "fruit_t"). Debugger VC10 ma wiele błędów, o ile wiem, więc informacje o typie wyświetlane powyżej są podejrzane. – jgx

+0

Mimo że mój debugger VS2010 pokazuje poprawne typy (owoce *), to zawiesza się na tych przydzielonych z auto. – RedX

Odpowiedz

1

Tak, myślę, że to błąd VS2010. Działając tak samo jak Ty (lub przynajmniej bardzo podobnie) z XP SP3 (32-bit) i VS2010 SP1, otrzymuję dokładnie ten sam błąd. Wygląda na to, że jest to specyficzne dla wyrażeń, ponieważ próba z klasami pokazała, że ​​wszystko działa poprawnie. Próbowałem też dodać do wyliczenia kolejny owocowy element o wartości 100000, aby upewnić się, że nie jest to coś tak głupiego, jak twoje wyliczenie mające wszystkie wartości poniżej 255. Ten sam wynik.

Zrobiłem szybkie wyszukiwanie na Microsoft Connect i nie widzę raportu o błędzie, więc polecam, aby wprowadzić jeden. To jest najlepszy sposób, aby upewnić się, że Microsoft wie i ewentualnie go naprawić.

+1

Ten błąd został naprawiony w VS2012, nie ma sensu składanie raportu zwrotnego. –

+5

Uważam, że nadal należy złożyć raport zwrotny. Po pierwsze, VS2012 nie jest jeszcze wydany. Co ważniejsze, nawet jeśli (kiedy) zostanie zamknięte jako "Nie naprawi", przynajmniej będzie dostępne dla innych osób. –

Powiązane problemy