Конфлікт між підручником у Стенфорді та GCC

Згідно з цим фільмом (близько хвилини 38), якщо я маю дві функції з однаковими місцевими варі, вони будуть використовувати той самий простір. Отже, наступну програму слід надрукувати 5. Складання його з gccрезультатами -1218960859. чому?

Програма:

#include <stdio.h>

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

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

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

за запитом, ось вихідні дані від розбирача:

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

Так, так, це невизначена поведінка , оскільки ви використовуєте змінну uninitialized ¹ .

Однак, на архітектурі x86 ² , цей експеримент повинен працювати . Значення не "стирається" зі стека, і оскільки воно не ініціалізоване B(), це те саме значення все одно повинно бути там, за умови, що кадри стека ідентичні.

Я наважуся здогадатися, що, оскільки int aвін не використовується всередині void B(), компілятор оптимізував цей код, і 5 ніколи не писалося в цьому місці в стеку. Спробуйте також додати printfin B()- це може просто спрацювати.

Крім того, прапорці компілятора - а саме рівень оптимізації - також, ймовірно, вплинуть і на цей експеримент. Спробуйте відключити оптимізацію, перейшовши -O0до gcc.

Редагувати: Я щойно скомпілював ваш код за допомогою 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.

Це невизначена поведінка . Неініціалізована локальна змінна має невизначене значення, і її використання призведе до невизначеної поведінки.

Важливо пам’ятати одне - ніколи не покладайтесь на щось подібне і ніколи не використовуйте це в реальному коді! Це просто цікава річ (що навіть не завжди відповідає дійсності), а не особливість чи щось подібне. Уявіть собі, що ви намагаєтеся знайти помилку, вироблену такою «особливістю» - кошмаром.

До речі. - C і C ++ наповнені такими "особливостями", ось ВЕЛИКИЙ слайд-шоу про це: http://www.slideshare.net/olvemaudal/deep-c Тож, якщо ви хочете побачити більше подібних "функцій", зрозумійте, що просто дивіться це слайд-шоу - ви не пошкодуєте, і я впевнений, що навіть більшість досвідчених програмістів на c / c ++ можуть багато чому навчитися.

У функції Aзмінна aне ініціалізується, друк її значення призводить до невизначеної поведінки.

У деякому компіляторі змінна ain Aі ain Bзнаходяться в одній адресі, тому вона може друкуватися 5, але знову ж таки, ви не можете покладатися на невизначену поведінку.

Складіть свій код за допомогою gcc -Wall filename.cВи побачите ці попередження.

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 Друк неініціалізованої змінної веде до невизначеної поведінки.

Розділ 6.7.8. Ініціалізація стандарту C99 говорить

Якщо об'єкт, що має автоматичну тривалість зберігання, не ініціалізується явно, його значення є невизначеним. Якщо об'єкт, який має статичну тривалість зберігання, не ініціалізований явно, тоді:

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

Редагувати1

Як @Jonathon Reinhart Якщо ви відключите оптимізацію за допомогою -Oпрапораgcc-O0 тоді ви можете отримати результат 5.

Але це зовсім не гарна ідея, ніколи не використовуйте це у виробничому коді.

-Wuninitialized це одне з цінних попереджень. Ви повинні розглянути це. Не слід ні вимикати, ні пропускати це попередження, яке призводить до величезних збитків у виробництві, таких як спричинення збоїв під час запуску демонів.

Редагувати2

Пояснення слайдів Deep C, чому результат 5 / сміття. Додавання цієї інформації з цих слайдів з незначними змінами, щоб зробити цю відповідь трохи ефективнішою.

Випадок 1: без оптимізації

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

Можливо, цей компілятор має пул іменованих змінних, які він використовує повторно. Наприклад, змінна a була використана і випущена B(), тоді, коли A()потрібні цілі імена, aвона отримає змінну і отримає те саме місце в пам'яті. Якщо ви перейменуєте змінну в B(), скажімо b, тоді я не думаю, що ви отримаєте 5.

Випадок 2: з оптимізацією

Багато речей може трапитися, коли ввімкнеться оптимізатор. У цьому випадку я гадаю, що виклик до B()можна пропустити, оскільки він не має побічних ефектів. Крім того, я не був би здивований, якщо A()вбудований символ main(), тобто відсутність виклику функції. (Але оскільки A ()має видимість компонувальника, об’єктний код функції все одно повинен бути створений на випадок, якщо інший об’єктний файл хоче пов’язати функцію). У будь-якому випадку, я підозрюю, що друковане значення буде чимось іншим, якщо ви оптимізуєте код.

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

Сміття!