Здравствуйте, dilmah, Вы писали:

D>Нигде не регламентируется, что для хранения автоматических переменных используется стандартный стек. Могут использоваться регистры.

Могут, но таки если мы берём адрес переменной, то оптимизатор несколько связан в своих действиях, вообще-то...

D>В данном случае оптимизирующий компилятор имеет полное право вообще вернуть мусор и будет прав.
Сложный это вопрос. Он в любом случае должен вернуть адрес из фрейма функции. Это наблюдаемое поведение же. Что должно лежать по адресу -- вопрос мутный. Например, можно переменную обозначить как волотильную

А вот и пример, как такой сценарий происходит в дикой природе — http://ideone.com/3wHAj

Тут есть два процесса. Первый в цикле вызывает функцию check. Эта функция вызывает f, в которой записывается в локальную переменную константа и возвращается указатель на эту переменную, после чего функция check проверяет что по указателю записана та же константа.
В таком состоянии первый процесс может работать очень долго — http://ideone.com/ynHNY (тут убран fork)

Но тут в дело вступает второй процесс. Он, конечно, никак напрямую не влияет на контекст первого процесса. Единственное, что он делает — это посылает сигналы.
И вот в момент, когда приходит сигнал, ОС приостанавливает первый процесс и выделяет в его стеке новый фрейм и попутно уничтожает все локальные переменных, из уже отживших функций.

Таким образом, если сигнал приходит в момент между строчками 21 и 22, то происходит перезапись памяти, а value оказывается равным другому значению — в этом случае программа печатает oops.

Здравствуйте, watch-maker, Вы писали:

S>>У такого обработчика дожен быть совершенно другой контекст по идее.
WM>По какой ещё идее? Обработчик же может принадлежать программе.
По той идее, что никаких обработчиков сигналов в данном примере нет.

S>>И следовательно другой стек.
WM>Создавать новый полноценный стек на каждый приход сигнала. Шутишь?
Я имел ввиду, что если в программе своего обработчика сигналов нет то значит имеется ввиду какой другой процесс и другой стек.

Здравствуйте, salvequick, Вы писали:

S>между int *m=f();
S>и value=m;
S>никаких вызовов нет. ничего не вызывается ,никто не трогает стек.

Между этими действиями в системе может образоваться дефицит памяти, ядро имеет право отправить процесс в своп, сохранив при этом только действительную часть стека, и отбросив все, что за указателем его вершины. При определенных условиях (например, вершина находится на границе страниц) после восстановлении процесса в памяти за пределами вершины может быть мусор.

Здравствуйте, salvequick, Вы писали:

S>По той идее, что никаких обработчиков сигналов в данном примере нет.

В той части процесса, которая получается из вышеприведенного кода — нет. А во всем процессе, в том числе в системных библиотеках — никто не знает, может и быть.

Здравствуйте, salvequick, Вы писали:

S>Я сам прокручивал самые разные версии вплоть до влияния ОС, процессорной архитектуры, типа компилятора и ключей оптимизации кода. Никаких результатов стабильно держится value=5 при всех комбинациях.

Влияние ОС? Да пожалуйста. Берём любую ОС без защиты памяти. Хоть MS-DOS, хоть что-нибудь микроконтроллерное.
Как там устроены прерывания? Очень просто. Это внезапный вызов системной функции, прямо на пользовательском стеке. (А уже оттуда система может переключить контекст, подменить стек и всё такое).
Естественно, что всё, что лежит ниже указателя стека, — затирается.

В отличие от процессоров с защитой, где прерывание — это сперва смена контекста (хотя бы по-простому, переключение банка регистров), а уже потом всё остальное.

Здравствуйте, rg45, Вы писали:

R>В отладочной конфигурации компилятор вполне может помечать освобожденную стековую память каким-нибудь определенным значением — для облегчения диагностики подобных ошибок.

А интерпретатор может вообще стек на списке фреймов залудить, например