Можно ли получить доступ к памяти локальной переменной вне ее области?

Как это может быть? Разве память локальной переменной не недоступна вне ее функции?

Вы снимаете номер в отеле. Вы кладете книгу в верхний ящик тумбочки и ложитесь спать. Вы выезжаете на следующее утро, но «забываете» вернуть ключ. Вы украли ключ!

Через неделю вы возвращаетесь в отель, не регистрируетесь, пробираетесь в свою старую комнату с украденным ключом и заглядываете в ящик. Ваша книга все еще там. Удивительный!

Как такое может быть? Разве содержимое ящика гостиничного номера недоступно, если вы не сняли номер?

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

Администрация отеля не обязана удалять вашу книгу. Вы не заключали с ними договор, в котором говорилось, что если вы оставите вещи, они их для вас разорвут. Если вы незаконно войдете в номер с украденным ключом, чтобы вернуть его, сотрудники службы безопасности отеля не обязаны задержать вас крадущимся. Вы не заключали с ними договор, в котором говорилось "если Я пытаюсь прокрасться в свою комнату позже, ты должен меня остановить ». Скорее, вы подписали с ними контракт, в котором говорилось: «Я обещаю не пробираться обратно в мою комнату позже», контракт, который вы разорвали.

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

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

C ++ - небезопасный язык. Это с радостью позволит вам нарушить правила системы. Если вы попытаетесь сделать что-то незаконное и глупое, например, вернуться в комнату, в которой вам не разрешено находиться, и рыться в столе, которого, возможно, даже нет, C ++ не остановит вас. Более безопасные языки, чем C ++, решают эту проблему, ограничивая ваши возможности - например, за счет более строгого контроля над ключами.

ОБНОВИТЬ

Боже мой, этот ответ привлекает много внимания. (Я не уверен, почему - я считал это просто забавной аналогией, но неважно.)

Я подумал, что было бы уместно немного обновить это, добавив еще несколько технических мыслей.

Компиляторы создают код, который управляет хранением данных, обрабатываемых этой программой. Существует множество различных способов создания кода для управления памятью, но со временем закрепились два основных метода.

Первый - иметь своего рода "долгоживущую" область хранения, где "время жизни" каждого байта в памяти - то есть период времени, когда он корректно связан с некоторой программной переменной - нельзя легко предсказать заранее. времени. Компилятор генерирует вызовы «диспетчера кучи», который знает, как динамически выделять память, когда она нужна, и возвращать ее, когда она больше не нужна.

Второй метод - иметь «недолговечную» область хранения, в которой время жизни каждого байта хорошо известно. Здесь воплощения следуют шаблону «вложенности». Самые долгоживущие из этих короткоживущих переменных будут выделены перед любыми другими короткоживущими переменными и будут освобождены в последнюю очередь. Короткоживущие переменные будут размещены после самых долгоживущих и будут освобождены до них. Время жизни этих короткоживущих переменных «вложено» в срок жизни более долгоживущих.

Локальные переменные следуют последнему шаблону; когда вводится метод, оживают его локальные переменные. Когда этот метод вызывает другой метод, оживают локальные переменные нового метода. Они умрут раньше, чем умрут локальные переменные первого метода. Относительный порядок начала и окончания срока службы хранилищ, связанных с локальными переменными, может быть определен заранее.

По этой причине локальные переменные обычно генерируются как хранилище в структуре данных «стек», потому что стек обладает тем свойством, что первое, что в него помещено, будет последним, что выскочит.

Это похоже на то, что отель решает сдавать комнаты только последовательно, и вы не можете выписаться, пока все, у кого номер комнаты выше, чем вы выселили.

Итак, давайте подумаем о стеке. Во многих операционных системах вы получаете один стек на поток, и стек выделяется определенного фиксированного размера. Когда вы вызываете метод, все содержимое помещается в стек. Если вы затем передадите указатель на стек обратно из вашего метода, как это делает исходный плакат, это будет просто указатель на середину некоторого полностью допустимого блока памяти размером в миллион байт. В нашей аналогии вы выезжаете из отеля; когда вы это сделаете, вы только что выехали из занятой комнаты с самым большим номером. Если после вас никто не зарегистрируется, и вы вернетесь в свой номер незаконно, все ваши вещи гарантированно останутся там в этом конкретном отеле.

Мы используем стеки для временных складов, потому что они действительно дешевы и просты. Реализация C ++ не требуется для использования стека для хранения локальных переменных; он мог использовать кучу. Это не так, потому что это замедлит работу программы.

Реализация C ++ не обязана оставлять мусор, который вы оставили в стеке, нетронутым, чтобы вы могли вернуться за ним позже незаконно; компилятор совершенно законно генерирует код, который обнуляет все в «комнате», которую вы только что освободили. Это не так, потому что, опять же, это было бы дорого.

Реализация C ++ не требуется, чтобы гарантировать, что когда стек логически сжимается, адреса, которые раньше были действительными, все еще отображались в памяти. Реализации разрешено сообщать операционной системе: «Мы закончили использовать эту страницу стека. Пока я не скажу иначе, создайте исключение, которое уничтожит процесс, если кто-либо коснется ранее действующей страницы стека». Опять же, реализации на самом деле этого не делают, потому что это медленно и ненужно.

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

Это проблематично. Правил очень много, и их очень легко случайно нарушить. Я, конечно, много раз. И что еще хуже, проблема часто возникает только тогда, когда обнаруживается, что память повреждена через миллиарды наносекунд после того, как произошло повреждение, когда очень трудно выяснить, кто это испортил.

Более безопасные для памяти языки решают эту проблему, ограничивая ваши возможности. В «обычном» C # просто нет возможности взять адрес локального и вернуть его или сохранить на потом. Вы можете взять адрес локального, но язык продуман так, что его невозможно использовать после окончания срока жизни локального. Чтобы взять адрес локального компьютера и передать его обратно, вы должны перевести компилятор в специальный «небезопасный» режим, и добавить слово «небезопасно» в вашу программу, чтобы привлечь внимание к факт, что вы, вероятно, делаете что-то опасное, что может нарушать правила.

Для дальнейшего чтения:

• Что, если бы C # позволял возвращать ссылки? По совпадению, это тема сегодняшнего сообщения в блоге:

  https://ericlippert.com/2011/06/23/ref-returns-and-ref-locals/

• Почему мы используем стеки для управления памятью? Всегда ли типы значений в C # хранятся в стеке? Как работает виртуальная память? И многие другие темы о том, как работает диспетчер памяти C #. Многие из этих статей также актуальны для программистов на C ++:

  https://ericlippert.com/tag/memory-management/

Здесь вы просто читаете и записываете в память, которая раньше была адресом a. Теперь, когда вы находитесь за пределами foo, это просто указатель на какую-то случайную область памяти. Так уж получилось, что в вашем примере эта область памяти действительно существует, и в данный момент больше ее не использует. Вы ничего не сломаете, продолжая его использовать, и ничто другое еще не перезаписало его. Следовательно, 5 все еще там. В реальной программе эта память будет повторно использована почти сразу, и вы что-нибудь сломаете, сделав это (хотя симптомы могут появиться гораздо позже!)

Когда вы возвращаетесь из foo, вы сообщаете ОС, что больше не используете эту память, и ее можно переназначить на что-то другое. Если вам повезет, и он никогда не будет переназначен, и ОС не поймает вас на его повторном использовании, то ложь вам сойдет с рук. Скорее всего, вы в конечном итоге переписываете все, что заканчивается этим адресом.

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

Вкратце: обычно это не срабатывает, но иногда случается.

Потому что пространство для хранения еще не было задействовано. Не рассчитывай на такое поведение.

Небольшое дополнение ко всем ответам:

если вы сделаете что-то подобное:

#include<stdio.h>
#include <stdlib.h>
int * foo(){
    int a = 5;
    return &a;
}
void boo(){
    int a = 7;

}
int main(){
    int * p = foo();
    boo();
    printf("%d\n",*p);
}

вывод, вероятно, будет: 7

Это потому, что после возврата из foo () стек освобождается и затем повторно используется boo (). Если вы разберете исполняемый файл, вы увидите его отчетливо.

В C ++ вы можете получить доступ к любому адресу, но это не значит, что вы должны. Адрес, к которому вы обращаетесь, больше не действителен. Это работает, потому что больше ничего не скремблирует память после возврата foo, но при многих обстоятельствах может произойти сбой. Попробуйте проанализировать свою программу с помощью Valgrind или просто скомпилировать ее с оптимизацией и посмотреть ...

Вы никогда не генерируете исключение C ++, обращаясь к недействительной памяти. Вы просто приводите пример общей идеи ссылки на произвольную ячейку памяти. Я мог бы сделать то же самое:

unsigned int q = 123456;

*(double*)(q) = 1.2;

Здесь я просто обрабатываю 123456 как адрес двойника и пишу ему. Может случиться любое количество вещей:

1. q на самом деле может быть действительным адресом двойника, например double p; q = &p;.
2. q может указывать где-то внутри выделенной памяти, и я просто перезаписываю там 8 байтов.
3. q указывает за пределы выделенной памяти, и диспетчер памяти операционной системы отправляет моей программе сигнал об ошибке сегментации, в результате чего среда выполнения завершает ее.
4. Вы выигрываете в лотерею.

То, как вы его настроили, немного более разумно, чтобы возвращаемый адрес указывал на допустимую область памяти, поскольку он, вероятно, будет немного дальше по стеку, но это все еще недопустимое место, к которому вы не можете получить доступ в детерминированная мода.

Никто не будет автоматически проверять семантическую валидность таких адресов памяти для вас при нормальном выполнении программы. Однако отладчик памяти, такой как valgrind, с радостью сделает это, поэтому вам следует запустить свою программу через него и увидеть ошибки.

Вы скомпилировали свою программу с включенным оптимизатором? Функция foo() довольно проста и могла быть встроена или заменена в результирующем коде.

Но я согласен с Марком Б в том, что результирующее поведение не определено.

Ваша проблема не имеет ничего общего с областью действия. В показанном вами коде функция main не видит имен в функции foo, поэтому вы не можете получить доступ к a в foo напрямую с этим именем за пределами foo.

Проблема, с которой вы столкнулись, заключается в том, почему программа не сигнализирует об ошибке при обращении к недопустимой памяти. Это связано с тем, что стандарты C ++ не определяют четкой границы между незаконной памятью и допустимой памятью. Ссылка на что-то в раскрывающемся стеке иногда вызывает ошибку, а иногда - нет. Это зависит. Не рассчитывайте на такое поведение. Предположим, что это всегда будет приводить к ошибке при программировании, но предположим, что он никогда не будет сигнализировать об ошибке при отладке.

Вы просто возвращаете адрес памяти, это разрешено, но, вероятно, это ошибка.

Да, если вы попытаетесь разыменовать этот адрес памяти, у вас будет неопределенное поведение.

int * ref () {

 int tmp = 100;
 return &tmp;
}

int main () {

 int * a = ref();
 //Up until this point there is defined results
 //You can even print the address returned
 // but yes probably a bug

 cout << *a << endl;//Undefined results
}

Это классическое неопределенное поведение, которое обсуждалось здесь не более двух дней назад - немного поищите по сайту. Короче говоря, вам повезло, но могло случиться что угодно, и ваш код делает недопустимый доступ к памяти.

Как отметил Алекс, это поведение не определено - на самом деле, большинство компиляторов предупреждают об этом, потому что это простой способ получить сбои.

В качестве примера жуткого поведения, которое вы вероятно столкнетесь, попробуйте этот пример:

int *a()
{
   int x = 5;
   return &x;
}

void b( int *c )
{
   int y = 29;
   *c = 123;
   cout << "y=" << y << endl;
}

int main()
{
   b( a() );
   return 0;
}

Это напечатает «y = 123», но ваши результаты могут отличаться (действительно!). Ваш указатель затирает другие, не связанные локальные переменные.

Обратите внимание на все предупреждения. Не только устраняйте ошибки.
GCC показывает это предупреждение

предупреждение: возвращен адрес локальной переменной 'a'

В этом сила C ++. Вам следует заботиться о памяти. С флагом -Werror это предупреждение становится ошибкой, и теперь вам нужно его отладить.

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

Фактически вы вызвали неопределенное поведение.

Возвращение адреса временных работ, но поскольку временные объекты уничтожаются в конце функции, результаты доступа к ним будут неопределенными.

Таким образом, вы не изменили a, а изменили место в памяти, где когда-то находился a. Эта разница очень похожа на разницу между сбоями и отсутствием сбоев.

В типичных реализациях компилятора код можно представить как «распечатать значение блока памяти с адресом, который раньше был занят». Кроме того, если вы добавляете вызов новой функции к функции, которая содержит локальный int, велика вероятность того, что значение a (или адрес памяти, на который указывает a) изменится. Это происходит потому, что стек будет перезаписан новым фреймом, содержащим другие данные.

Однако это неопределенное поведение, и вам не следует полагаться на его работу!

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

То, что вы делаете, описывается как неопределенное поведение. Результат невозможно предугадать.

Вещи с правильным (?) Выводом в консоль могут кардинально измениться, если вы используете :: printf, но не cout. Вы можете поиграть с отладчиком в приведенном ниже коде (протестировано на x86, 32-разрядной версии, MSVisual Studio):

char* foo() 
{
  char buf[10];
  ::strcpy(buf, "TEST”);
  return buf;
}

int main() 
{
  char* s = foo();    //place breakpoint & check 's' varialbe here
  ::printf("%s\n", s); 
}

После возврата из функции все идентификаторы уничтожаются вместо сохраненных значений в ячейке памяти, и мы не можем найти значения, не имея идентификатора, но это место по-прежнему содержит значение, сохраненное предыдущей функцией.

Итак, здесь функция foo() возвращает адрес a, а a уничтожается после возврата его адреса. И вы можете получить доступ к измененному значению через этот возвращенный адрес.

Рассмотрим пример из реальной жизни:

Предположим, человек прячет деньги в каком-то месте и сообщает вам это место. Через какое-то время человек, сказавший вам местонахождение денег, умирает. Но все же у вас есть доступ к этим скрытым деньгам.

Это «грязный» способ использования адресов памяти. Когда вы возвращаете адрес (указатель), вы не знаете, принадлежит ли он локальной области видимости функции. Это просто адрес. Теперь, когда вы вызвали функцию 'foo', этот адрес (ячейка памяти) 'a' уже был выделен там в (по крайней мере, пока безопасно) адресуемой памяти вашего приложения (процесса). После возврата функции 'foo' адрес 'a' можно считать 'грязным', но он есть, не очищен, не нарушен / не изменен выражениями в другой части программы (по крайней мере, в этом конкретном случае). Компилятор C / C ++ не останавливает вас от такого «грязного» доступа (хотя может вас предупредить, если вам не все равно). Вы можете безопасно использовать (обновлять) любую ячейку памяти, которая находится в сегменте данных вашего экземпляра программы (процесса), если вы не защитите адрес каким-либо образом.

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

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

Это означает, что вы делаете очень плохой поступок, потому что вы передаете адрес памяти указателю, которому вообще нельзя доверять.

Вместо этого рассмотрим этот пример и протестируем его:

int * foo()
{
   int *x = new int;
   *x = 5;
   return x;
}

int main()
{
    int* p = foo();
    std::cout << *p << "\n"; //better to put a new-line in the output, IMO
    *p = 8;
    std::cout << *p;
    delete p;
    return 0;
}

В отличие от вашего примера, в этом примере вы:

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

Это зависит от языка. В C & C ++ / Cpp, ДА, вы технически могли бы, потому что он имеет очень слабые проверки того, действительно ли какой-либо указанный указатель указывает на действительный или нет. Компилятор сообщит об ошибке, если вы попытаетесь получить доступ к самой переменной, когда она находится вне области видимости, но он вряд ли будет достаточно умен, чтобы знать, намеренно ли вы копируете указатель на местоположение этой переменной в какой-либо другая переменная, которая останется в области видимости позже.

Однако изменение этой памяти после того, как переменная выходит за пределы области видимости, будет иметь совершенно неопределенный эффект. Вы, вероятно, повредите стек, который мог повторно использовать это пространство для новых переменных.

Более современные языки, такие как Java или C #, часто делают все возможное, чтобы программисту в первую очередь не требовался доступ к фактическим адресам переменных, а также доступ к массивам с проверкой границ и сохранением ссылок. количество переменных, которые указывают на объекты в куче, чтобы они не освобождались преждевременно, и так далее. Все это предназначено для того, чтобы помочь программисту не сделать что-то непреднамеренно небезопасное и / или выходящее за пределы переменных в области видимости.