[c] Stanford 자습서와 GCC 간의 충돌

예, 예, 이것은 uninitialized ¹ 변수를 사용하고 있기 때문에 정의되지 않은 동작 입니다.

그러나 x86 아키텍처 ² 에서는 이 실험이 작동 합니다. 값은 스택에서 “삭제”되지 않으며에서 초기화되지 않았기 때문에 B()스택 프레임이 동일하다면 동일한 값이 여전히 존재해야합니다.

나는 내부에서 사용int a 되지 않기 때문에 컴파일러가 해당 코드를 최적화했으며 5는 스택의 해당 위치에 기록되지 않았다고 생각합니다. 추가 시도 의를void B()printfB() 그냥 작동 할 수 있습니다 – 물론.

또한 컴파일러 플래그 (즉, 최적화 수준)도이 실험에 영향을 미칠 수 있습니다. -O0gcc 로 전달 하여 최적화를 비활성화하십시오 .

편집 : 방금 코드를 gcc -O0(64 비트)로 컴파일 했으며 실제로 프로그램은 호출 스택에 익숙한 사람이 예상하는 것처럼 5를 인쇄합니다. 실제로 -O0. 32 비트 빌드는 다르게 동작 할 수 있습니다.

면책 조항 : 음주하지 영원히, 영원히 “진짜”코드 같은 것을 사용!

_{1- 이것이 공식적으로 “UB”인지 아니면 단지 예측할 수 없는지 에 대한 논쟁이 계속되고 있습니다 .}

_{2-또한 x64 및 호출 스택을 사용하는 다른 모든 아키텍처 (최소한 MMU가있는 아키텍처)}

작동 하지 않는 이유를 살펴 보겠습니다 . 이것은 32 비트에서 가장 잘 볼 수 있으므로 -m32.

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

$ gcc -m32 -O0 test.c(최적화 비활성화)로 컴파일했습니다 . 이것을 실행하면 쓰레기가 인쇄됩니다.

보고 $ 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

우리는 점에서 볼 B, 컴파일러는 스택 공간을 0x10 바이트를 예약하고, 우리의 초기화 int a에 변수를 [ebp-0x4]5.

에서 A그러나, 컴파일러는 배치 int a에서 [ebp-0xc]. 따라서이 경우 우리의 지역 변수 는 같은 위치에 있지 않았습니다 ! 추가하는 것으로 써 printf()의 통화 A뿐만위한 스택 프레임 발생할하면서 A와 B동일하고, 인쇄 55.