Xung đột giữa hướng dẫn Stanford và GCC

Theo bộ phim này (khoảng phút 38), nếu tôi có hai chức năng với các vars cục bộ giống nhau, chúng sẽ sử dụng cùng một không gian. Vì vậy, chương trình sau đây, nên in 5. Biên dịch nó với gcckết quả -1218960859. tại sao?

Chương trình:

#include <stdio.h>

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

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

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

như được yêu cầu, đây là đầu ra từ trình tháo gỡ:

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

Vâng, vâng, đây là hành vi không xác định , vì bạn đang sử dụng biến chưa khởi tạo ¹ .

Tuy nhiên, trên kiến ​​trúc x86 ² , thử nghiệm này sẽ hoạt động . Giá trị không bị "xóa" khỏi ngăn xếp và vì nó không được khởi tạo trong B()nên giá trị đó vẫn sẽ ở đó, miễn là các khung ngăn xếp giống hệt nhau.

Tôi muốn đoán rằng, vì int akhông được sử dụng bên trong void B(), trình biên dịch đã tối ưu hóa mã đó và số 5 không bao giờ được ghi vào vị trí đó trên ngăn xếp. Hãy thử thêm printfvào B()- nó chỉ có thể hoạt động.

Ngoài ra, cờ trình biên dịch - cụ thể là mức tối ưu hóa - cũng có thể sẽ ảnh hưởng đến thử nghiệm này. Thử tắt tối ưu hóa bằng cách chuyển -O0sang gcc.

Chỉnh sửa: Tôi vừa mới biên dịch mã của bạn với gcc -O0(64-bit) và thực sự, chương trình in ra 5, như một người quen thuộc với ngăn xếp cuộc gọi mong đợi. Trong thực tế, nó hoạt động ngay cả khi không có -O0. Bản dựng 32 bit có thể hoạt động khác.

Tuyên bố từ chối trách nhiệm: Đừng bao giờ, đừng bao giờ sử dụng những thứ như thế này trong mã "thực"!

_{1 - Có một cuộc tranh luận đang diễn ra bên dưới về việc liệu đây có phải là "UB" chính thức hay không, hay chỉ là không thể đoán trước.}

_{2 - Ngoài ra x64 và có thể là mọi kiến ​​trúc khác sử dụng ngăn xếp cuộc gọi (ít nhất là những kiến ​​trúc có MMU)}

Hãy xem một lý do tại sao nó không hoạt động. Điều này được nhìn thấy tốt nhất trong 32 bit, vì vậy tôi sẽ biên dịch với -m32.

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

Tôi đã biên dịch với $ gcc -m32 -O0 test.c(Tối ưu hóa bị vô hiệu hóa). Khi tôi chạy cái này, nó in ra rác.

Nhìn vào $ 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    

Chúng ta thấy rằng trong B, trình biên dịch dành riêng 0x10 byte không gian ngăn xếp và khởi tạo int abiến của chúng ta ở mức [ebp-0x4]5.

Trong Atuy nhiên, trình biên dịch đặt int atại [ebp-0xc]. Vì vậy, trong trường hợp này, các biến cục bộ của chúng ta không kết thúc ở cùng một vị trí! Bằng cách thêm một printf()cuộc gọi trong Acũng sẽ gây ra các khung stack cho Avà Bđể được giống hệt nhau, và in 55.

Đó là hành vi không xác định . Một biến cục bộ chưa được khởi tạo có giá trị không xác định và việc sử dụng nó sẽ dẫn đến hành vi không xác định.

Một điều quan trọng cần nhớ - đừng bao giờ dựa vào những thứ như thế và đừng bao giờ sử dụng điều này trong mã thực! Đó chỉ là một điều thú vị (thậm chí không phải lúc nào cũng đúng), không phải là một tính năng hay một thứ gì đó tương tự. Hãy tưởng tượng bạn đang cố gắng tìm ra lỗi được tạo ra bởi loại "tính năng" đó - cơn ác mộng.

Btw. - C và C ++ có đầy đủ loại "tính năng" đó, đây là trình chiếu TUYỆT VỜI về nó: http://www.slideshare.net/olvemaudal/deep-c Vì vậy, nếu bạn muốn xem thêm các "tính năng" tương tự, hãy hiểu những gì dưới mui xe và cách nó hoạt động chỉ cần xem trình chiếu này - bạn sẽ không hối tiếc và tôi chắc chắn rằng ngay cả hầu hết các lập trình viên c / c ++ có kinh nghiệm cũng có thể học được nhiều điều từ điều này.

Trong hàm A, biến akhông được khởi tạo, việc in giá trị của nó dẫn đến hành vi không xác định.

Trong một số trình biên dịch, biến ain Avà ain Bở cùng một địa chỉ, vì vậy nó có thể in ra 5, nhưng một lần nữa, bạn không thể dựa vào hành vi không xác định.

Biên dịch mã của bạn với gcc -Wall filename.cBạn sẽ thấy những cảnh báo này.

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]  

Trong c In biến chưa được khởi tạo Dẫn đến hành vi Không xác định.

Phần 6.7.8 Khởi tạo tiêu chuẩn C99 cho biết

Nếu một đối tượng có thời lượng lưu trữ tự động không được khởi tạo rõ ràng, giá trị của nó là không xác định. Nếu một đối tượng có thời lượng lưu trữ tĩnh không được khởi tạo rõ ràng, thì:

— 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.

Chỉnh sửa1

Như @Jonathon Reinhart Nếu bạn tắt tối ưu hóa bằng cách Sử dụng -Ocờ gcc-O0 thì bạn có thể nhận được đầu ra 5.

Nhưng đây hoàn toàn không phải là ý kiến ​​hay, đừng bao giờ sử dụng điều này trong mã sản xuất.

-Wuninitialized Đây là một trong những cảnh báo có giá trị. Bạn nên cân nhắc cảnh báo này Bạn không nên vô hiệu hóa hoặc bỏ qua cảnh báo này, dẫn đến thiệt hại lớn trong quá trình sản xuất như gây ra sự cố trong khi chạy trình duyệt.

Edit2

Các trang trình bày Deep C giải thích Tại sao kết quả là 5 / rác. Thêm thông tin này từ các trang trình bày đó với các sửa đổi nhỏ để làm cho câu trả lời này hiệu quả hơn một chút.

Trường hợp 1: không có tối ưu hóa

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

Có lẽ trình biên dịch này có một nhóm các biến được đặt tên mà nó sử dụng lại. Ví dụ: biến a đã được sử dụng và phát hành B(), sau đó khi A()cần một số nguyên tên anó sẽ nhận được biến sẽ nhận được cùng một vị trí bộ nhớ. Nếu bạn đổi tên biến B()thành, giả sử b, thì tôi không nghĩ bạn sẽ nhận được 5.

Trường hợp 2: có tối ưu hóa

Rất nhiều điều có thể xảy ra khi trình tối ưu hóa hoạt động. Trong trường hợp này, tôi đoán rằng lệnh gọi đến B()có thể bị bỏ qua vì nó không có bất kỳ tác dụng phụ nào. Ngoài ra, tôi sẽ không ngạc nhiên nếu hàm A()được gạch trong main(), tức là không có lệnh gọi hàm. (Nhưng vì A ()có khả năng hiển thị trình liên kết, mã đối tượng cho hàm vẫn phải được tạo trong trường hợp tệp đối tượng khác muốn liên kết với hàm). Dù sao, tôi nghi ngờ giá trị được in sẽ là một cái gì đó khác nếu bạn tối ưu hóa mã.

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

Rác rưởi!