Stanford öğreticisi ile GCC arasındaki çelişki

Bu filme göre (yaklaşık 38 dakika), aynı yerel değişkenlere sahip iki fonksiyonum varsa, aynı alanı kullanacaklar. Yani aşağıdaki program yazdırılmalıdır 5. gccSonuçlarla derlemek -1218960859. neden?

Program:

#include <stdio.h>

void A()
{
    int a;
    printf("%i",a);
}

void B()
{
    int a;
    a = 5;
}

int main()
{
    B();
    A();
    return 0;
}

talep edildiği gibi, sökücünün çıktısı:

0804840c <A>:
 804840c:   55                      push   ebp
 804840d:   89 e5                   mov    ebp,esp
 804840f:   83 ec 28                sub    esp,0x28
 8048412:   8b 45 f4                mov    eax,DWORD PTR [ebp-0xc]
 8048415:   89 44 24 04             mov    DWORD PTR [esp+0x4],eax
 8048419:   c7 04 24 e8 84 04 08    mov    DWORD PTR [esp],0x80484e8
 8048420:   e8 cb fe ff ff          call   80482f0 <printf@plt>
 8048425:   c9                      leave  
 8048426:   c3                      ret    

08048427 <B>:
 8048427:   55                      push   ebp
 8048428:   89 e5                   mov    ebp,esp
 804842a:   83 ec 10                sub    esp,0x10
 804842d:   c7 45 fc 05 00 00 00    mov    DWORD PTR [ebp-0x4],0x5
 8048434:   c9                      leave  
 8048435:   c3                      ret    

08048436 <main>:
 8048436:   55                      push   ebp
 8048437:   89 e5                   mov    ebp,esp
 8048439:   83 e4 f0                and    esp,0xfffffff0
 804843c:   e8 e6 ff ff ff          call   8048427 <B>
 8048441:   e8 c6 ff ff ff          call   804840c <A>
 8048446:   b8 00 00 00 00          mov    eax,0x0
 804844b:   c9                      leave  
 804844c:   c3                      ret    
 804844d:   66 90                   xchg   ax,ax
 804844f:   90                      nop

Evet, evet, bu tanımlanmamış bir davranış çünkü ilklendirilmemiş ¹ değişkenini kullanıyorsunuz .

Ancak, x86 mimarisine ² , bu deney çalışması gerekir . Değer yığından "silinmez" ve içinde başlatılmadığından B(), yığın çerçevelerinin aynı olması koşuluyla aynı değer hala orada olmalıdır.

Beri, tahmin girişim ediyorum int adeğildir kullanılan iç bölgesinin void B(), bu kod dışarı optimize derleyici ve 5 yığın bu konuma yazılı değildi. Bir printfgiriş eklemeyi B()de deneyin - işe yarayabilir.

Ayrıca, derleyici işaretleri - yani optimizasyon seviyesi - bu deneyi de etkileyecektir. -O0Gcc'ye geçerek optimizasyonları devre dışı bırakmayı deneyin .

Düzenleme: Kodunuzu gcc -O0(64-bit) ile derledim ve aslında, program çağrı yığınına aşina birinin bekleyeceği gibi 5 yazdırır. Aslında, onsuz bile çalıştı -O0. 32 bitlik yapı farklı davranabilir.

Sorumluluk reddi: Asla, asla "gerçek" kodda böyle bir şey kullanmayın!

_{1 - Aşağıda bunun resmi olarak "UB" olup olmadığı veya sadece tahmin edilemez olup olmadığı hakkında bir tartışma var .}

_{2 - Ayrıca x64 ve muhtemelen bir çağrı yığını kullanan diğer tüm mimariler (en azından bir MMU'ya sahip olanlar)}

Bunun neden işe yaramadığına bir bakalım . Bu en iyi 32 bit'te görülür, bu yüzden -m32.

$ gcc --version
gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)

$ gcc -m32 -O0 test.c(Optimizasyonlar devre dışı bırakıldı) ile derledim . Bunu çalıştırdığımda, çöp yazdırıyor.

Bakmak $ objdump -Mintel -d ./a.out:

080483ec <A>:
 80483ec:   55                      push   ebp
 80483ed:   89 e5                   mov    ebp,esp
 80483ef:   83 ec 28                sub    esp,0x28
 80483f2:   8b 45 f4                mov    eax,DWORD PTR [ebp-0xc]
 80483f5:   89 44 24 04             mov    DWORD PTR [esp+0x4],eax
 80483f9:   c7 04 24 c4 84 04 08    mov    DWORD PTR [esp],0x80484c4
 8048400:   e8 cb fe ff ff          call   80482d0 <printf@plt>
 8048405:   c9                      leave  
 8048406:   c3                      ret    

08048407 <B>:
 8048407:   55                      push   ebp
 8048408:   89 e5                   mov    ebp,esp
 804840a:   83 ec 10                sub    esp,0x10
 804840d:   c7 45 fc 05 00 00 00    mov    DWORD PTR [ebp-0x4],0x5
 8048414:   c9                      leave  
 8048415:   c3                      ret    

BDerleyicinin 0x10 baytlık yığın alanı ayırdığını ve int adeğişkenimizi [ebp-0x4]5 olarak başlattığını görüyoruz .

Olarak A, ancak derleyici yerleştirilmiş int aen [ebp-0xc]. Yani bu durumda yerel değişkenlerimiz aynı yerde olmadı ! Bir ekleyerek printf()aramayı Ade için yığın çerçeveleri neden olarak Ave Baynı olması ve baskı 55.

Bu var tanımsız davranış . İlklendirilmemiş bir yerel değişkenin belirsiz bir değeri vardır ve onu kullanmak tanımsız davranışa yol açar.

Bir önemli şey hatırlamak - yok hiç böyle bir şeye güvenmek ve asla gerçek kodda bunu kullanın! Bu sadece ilginç bir şeydir (ki bu her zaman doğru değildir), bir özellik ya da onun gibi bir şey değil. Kendinizi bu tür bir "özellik" - kabus tarafından üretilen bir hatayı bulmaya çalıştığınızı hayal edin.

Btw. - C ve C ++ bu tür "özelliklerle" doludur, işte BÜYÜK slayt gösterisi: http://www.slideshare.net/olvemaudal/deep-c Yani daha benzer "özellikler" görmek istiyorsanız, ne olduğunu anlayın Kaputun altında ve nasıl çalıştığını sadece bu slayt gösterisini izleyin - pişman olmayacaksınız ve eminim ki deneyimli c / c ++ programcılarının çoğu bile bundan çok şey öğrenebilir.

Fonksiyonda A, değişken abaşlatılmaz, değerinin yazdırılması tanımsız davranışa yol açar.

Bazı derleyici olarak, değişken aiçinde Ave ade Bo yazdırabilirsiniz böylece, aynı adrese içindedir 5, ama yine sen tanımsız davranış güvenemez.

Kodunuzu ile derleyin gcc -Wall filename.cBu uyarıları göreceksiniz.

In function 'B':
11:9: warning: variable 'a' set but not used [-Wunused-but-set-variable]

In function 'A':
6:11: warning: 'a' is used uninitialized in this function [-Wuninitialized]  

C Başlatılmamış değişkeni yazdırma Tanımsız davranışa yol açar.

Bölüm 6.7.8 C99 standardının başlatılması diyor ki

Otomatik depolama süresi olan bir nesne açıkça başlatılmazsa, değeri belirsizdir. Statik depolama süresine sahip bir nesne açıkça başlatılmadıysa, o zaman:

— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules;
— if it is a union, the first named member is initialized (recursively) according to these rules.

Düzenle1

@Jonathon Reinhart olarak -OBayrak kullanarak optimizasyonu devre dışı bırakırsanız gcc-O0 çıktı 5 alabilirsiniz.

Ancak bu hiç de iyi bir fikir değil, bunu asla üretim kodunda kullanmayın.

-Wuninitialized bu değerli uyarılardan biridir Bunu göz önünde bulundurmalısınız Arka plan programlarını çalıştırırken çökmelere neden olmak gibi üretimde büyük hasara neden olan bu uyarıyı devre dışı bırakmamalı veya atlamamalısınız.

Düzenle2

Derin C slaytları, sonuç neden 5 / çöp olduğunu açıkladı.

Durum 1: optimizasyon olmadan

$ gcc -O0 file.c && ./a.out  
5

Belki de bu derleyicinin yeniden kullandığı bir adlandırılmış değişken havuzu vardır. Örneğin a değişkeni kullanıldı ve yayınlandı B(), daha sonra A()bir tamsayı ismine ihtiyaç duyduğunda adeğişken aynı bellek konumunu alacak. İçinde değişkeni yeniden adlandırırsanız B(), diyelim ki b, o zaman alacak sanmıyorum 5.

Durum 2: optimizasyonla

Optimizer devreye girdiğinde birçok şey olabilir. Bu durumda B(), herhangi bir yan etkisi olmadığı için çağrının atlanabileceğini tahmin ediyorum . Ayrıca, A()satır içi olarak main(), yani işlev çağrısı yoksa şaşırmam . (Ancak A ()bağlayıcı görünürlüğü olduğundan, işlevin nesne kodu, başka bir nesne dosyasının işlevle bağlantı kurmak istemesi durumunda yine de oluşturulmalıdır). Her neyse, kodu optimize ederseniz yazdırılan değerin başka bir şey olacağından şüpheleniyorum.

gcc -O file.c && ./a.out
1606415608  

Çöp!