범위 밖에서 지역 변수의 메모리에 접근 할 수 있습니까?

다음 코드가 있습니다.

#include <iostream>

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

int main()
{
    int* p = foo();
    std::cout << *p;
    *p = 8;
    std::cout << *p;
}

그리고 런타임 예외없이 코드가 실행 중입니다!

출력은 58

어떻게 할 수 있습니까? 함수 외부에서 로컬 변수의 메모리에 액세스 할 수 없습니까?

어떻게 할 수 있습니까? 함수 외부에서 로컬 변수의 메모리에 액세스 할 수 없습니까?

호텔 방을 임대하십시오. 침대 옆 테이블의 상단 서랍에 책을 넣고 자러갑니다. 다음날 아침에 체크 아웃하지만 열쇠를 돌려주는 것을 잊어 버렸습니다. 열쇠를 훔쳐!

일주일 후, 당신은 호텔로 돌아와 체크인하지 않고 열쇠를 훔친 오래된 방으로 몰래 들어가서 서랍을 봅니다. 당신의 책은 여전히 ​​있습니다. 놀라운!

어떻게 그렇게 될수 있니? 방을 임대하지 않은 경우 호텔 방 서랍의 내용에 액세스 할 수 없습니까?

분명히,이 시나리오는 현실 세계에서 아무 문제없이 일어날 수 있습니다. 더 이상 방에있을 권한이 없을 때 책이 사라지는 신비한 힘은 없습니다. 도난당한 열쇠로 방에 들어 가지 못하게하는 신비한 힘도 없습니다.

호텔 관리자는 책을 제거 할 필요 가 없습니다 . 당신이 물건을 남겨두면 그들은 당신을 위해 그것을 파쇄 할 것이라고 말했다 당신은 그들과 계약을하지 않았다. 열쇠를 훔쳐 열쇠를 가지고 불법적으로 방에 다시 들어간 경우에는 호텔 경비원이 당신을 몰래 잡을 필요 가 없습니다 . "내가 몰래 들어 오려고하면 나중에 방을 막아야합니다. " 오히려, 당신은 계약 "나중에 내 방으로 다시 몰래하지 않겠다고 약속"고 말했다 그들과 계약을 체결 당신이 파산을 .

이 상황에서는 어떤 일이든 일어날 수 있습니다 . 책은 거기있을 수 있습니다. 운이 좋았습니다. 다른 사람의 책이있을 수 있으며 호텔의 화로에있을 수도 있습니다. 당신이 들어 와서 책을 여러 조각으로 찢어 버릴 수 있습니다. 호텔에서 테이블을 제거하고 완전히 예약하여 옷장으로 교체했을 수 있습니다. 호텔 전체가 찢겨지고 축구 경기장으로 교체 될 수 있으며, 몰래 숨을 쉴 때 폭발로 사망 할 수 있습니다.

당신은 무슨 일이 일어날 지 모른다. 당신이 호텔에서 체크 아웃 불법 나중에 사용하기 위해 키를 훔쳐 때, 당신 때문에 예측, 안전한 세상에서 살 권리 포기 는 시스템의 규칙을 깰 선택합니다.

C ++는 안전한 언어가 아닙니다 . 유쾌하게 시스템의 규칙을 어길 수 있습니다. 만약 당신이 방으로 돌아가는 것처럼 불법적이고 어리석은 짓을하려고한다면 더 이상 없을 수도있는 책상을 통해 들어갈 수 없으며 C ++은 당신을 막을 수 없습니다. C ++보다 안전한 언어는 예를 들어 키를 훨씬 엄격하게 제어하여 전력을 제한함으로써이 문제를 해결합니다.

최신 정보

신의 선하심,이 대답은 많은 주목을 받고 있습니다. (왜 그런지 잘 모르겠다. 나는 그것이 단지 "재미있는"작은 비유라고 생각했다.

나는 약간의 기술적 인 생각으로 이것을 조금 업데이트하는 것이 독창적이라고 생각했다.

컴파일러는 해당 프로그램에 의해 조작 된 데이터의 저장을 관리하는 코드를 생성하는 사업에 있습니다. 메모리를 관리하기 위해 코드를 생성하는 방법에는 여러 가지가 있지만 시간이 지남에 따라 두 가지 기본 기술이 확립되었습니다.

첫 번째는 스토리지에있는 각 바이트의 "수명"즉, 일부 프로그램 변수와 유효하게 연관된 기간을 미리 쉽게 예측할 수없는 일종의 "긴 수명"스토리지 영역을 갖는 것입니다. 시간. 컴파일러는 필요할 때 스토리지를 동적으로 할당하고 더 이상 필요하지 않은 경우이를 회수하는 방법을 알고있는 "힙 관리자"에 대한 호출을 생성합니다.

두 번째 방법은 각 바이트의 수명이 잘 알려진 "짧은 수명"저장 영역을 갖는 것입니다. 여기서 수명은 "중첩"패턴을 따릅니다. 이 수명이 가장 짧은 변수는 다른 수명이 짧은 변수보다 먼저 할당되고 마지막에 해제됩니다. 수명이 짧은 변수는 수명이 가장 긴 변수 다음에 할당되고 변수가 해제되기 전에 해제됩니다. 수명이 짧은 변수의 수명은 수명이 긴 변수의 수명 내에 "중첩"됩니다.

지역 변수는 후자의 패턴을 따릅니다. 메소드가 입력되면 로컬 변수가 활성화됩니다. 해당 메소드가 다른 메소드를 호출하면 새 메소드의 로컬 변수가 활성화됩니다. 첫 번째 방법의 지역 변수가 죽기 전에 죽을 것입니다. 지역 변수와 관련된 스토리지 수명의 시작과 끝의 상대적 순서는 미리 해결할 수 있습니다.

이러한 이유로 로컬 변수는 일반적으로 "스택"데이터 구조의 저장소로 생성됩니다. 스택에는 첫 번째로 푸시 된 속성이 마지막으로 생성 된 속성이 있기 때문입니다.

호텔이 순차적으로 객실을 임대하기로 결정한 것처럼 객실 번호가 높은 사람이 모두 체크 아웃 할 때까지 체크 아웃 할 수 없습니다.

스택에 대해 생각해 봅시다. 많은 운영 체제에서 스레드 당 하나의 스택이 생성되고 스택은 특정 고정 크기로 할당됩니다. 메소드를 호출하면, 내용물이 스택으로 푸시됩니다. 그런 다음 원래 포스터에서와 같이 메소드에서 스택으로 포인터를 다시 전달하면 완전히 유효한 백만 바이트 메모리 블록의 중간에 대한 포인터 일뿐입니다. 우리의 비유로, 당신은 호텔을 체크 아웃합니다; 당신이 할 때, 당신은 방금 가장 높은 자리를 체크 아웃했습니다. 다른 사람이 체크인 한 후 아무도 체크인하지 않고 불법적으로 방으로 돌아 가면 모든 물건 이이 특정 호텔에 여전히 있어야 합니다.

스택은 실제로 저렴하고 쉬우므로 임시 저장소에 스택을 사용합니다. C ++ 구현은 로컬 저장을 위해 스택을 사용하지 않아도됩니다. 힙을 사용할 수 있습니다. 그것은 프로그램을 느리게 만들 것이기 ​​때문에 그렇지 않습니다.

C ++의 구현은 스택에 남겨둔 쓰레기를 건드리지 않고 나중에 불법으로 다시 올릴 수 있도록 요구하지 않습니다. 방금 비운 "방"의 모든 것을 0으로 되 돌리는 코드를 컴파일러가 생성하는 것은 완전히 합법적입니다. 다시 비싸지 않기 때문에 비용이 많이 듭니다.

스택이 논리적으로 축소 될 때 유효했던 주소가 여전히 메모리에 매핑되도록 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여전히 있습니다. 실제 프로그램에서, 그 메모리는 거의 즉시 재사용 될 것이고 당신은 이것을함으로써 무언가를 깰 것입니다.

에서 돌아 오면 fooOS에 더 이상 해당 메모리를 사용하지 않고 다른 것으로 재 할당 할 수 있다고 알려줍니다. 운이 좋고 다시 할당되지 않고 OS에서 다시 사용하지 않으면 거짓말을 피할 수 있습니다. 기회는 당신이 그 주소로 끝나는 모든 것을 작성하게 될 것입니다.

이제 컴파일러가 왜 불평하지 않는지 궁금하다면 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을 double의 주소로 취급하여 작성합니다. 여러 가지 일이 발생할 수 있습니다.

1. q실제로 실제로 double의 유효한 주소 일 수 있습니다 (예 :) double p; q = &p;.
2. q 할당 된 메모리 내부 어딘가를 가리킬 수 있으며 8 바이트를 덮어 씁니다.
3. q 할당 된 메모리 외부의 포인트와 운영 체제의 메모리 관리자가 세그먼트 오류 신호를 내 프로그램으로 보내 런타임으로 인해 메모리가 종료됩니다.
4. 당신은 복권에 당첨됩니다.

설정 방법은 반환 된 주소가 유효한 메모리 영역을 가리키는 것이 더 합리적입니다. 아마 스택에서 조금 더 떨어져 있기는하지만 여전히 액세스 할 수없는 잘못된 위치입니다 결정 론적 패션.

정상적인 프로그램 실행 중에는 메모리 주소의 의미 론적 유효성을 자동으로 확인하지 않습니다. 그러나 메모리 디버거와 같은 작업 valgrind은 행복하게 수행되므로 프로그램을 실행하여 오류를 확인해야합니다.

옵티 마이저를 사용하여 프로그램을 컴파일 했습니까? 이 foo()함수는 매우 간단하며 결과 코드에서 인라인되거나 대체되었을 수 있습니다.

그러나 결과적인 동작이 정의되지 않았다는 마크 B에 동의합니다.

당신의 문제는 범위 와 아무 관련이 없습니다 . 표시하는 코드에서 함수 main는 함수 의 이름을 볼 foo수 없으므로 외부 에서이 이름으로 afoo에서 직접 액세스 할 수 없습니다 .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
}

그것은 이틀 전에 논의 되지 않은 고전적인 정의되지 않은 행동 입니다. 사이트를 조금만 검색하십시오. 간단히 말해서 운이 좋았지 만 어떤 일이 있었을 수 있으며 코드가 메모리에 잘못 액세스하고 있습니다.

Alex가 지적한 것처럼이 동작은 정의되어 있지 않습니다. 실제로 대부분의 컴파일러는 충돌을 일으키는 쉬운 방법이기 때문에이 작업을 수행하지 않도록 경고합니다.

당신이 무시 무시한 행동의 종류의 예를 들어 가능성이 얻을,이 샘플을 시도 :

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. 이 차이는 충돌과 충돌하지 않는 차이와 매우 유사합니다.

일반적인 컴파일러 구현에서는 코드를 " 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'의 주소는 '더러운'것으로 간주 될 수 있지만, 프로그램의 다른 부분 (적어도이 경우에는)의 표현식에 의해 정리되지 않거나 방해 받거나 수정되지 않습니다. AC / 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를위한 메모리 할당
• 해당 메모리 주소는 기능이 만료 된 경우에도 여전히 유효합니다 (아무도 삭제하지 않음)
• 메모리 주소를 신뢰할 수 있음 (메모리 블록은 사용 가능한 것으로 간주되지 않으므로 삭제 될 때까지 무시되지 않음)
• 사용하지 않을 때는 메모리 주소를 삭제해야합니다. (프로그램 끝에서 삭제 참조)