问题:是否可以在其范围之外访问局部变量的内存?

我有以下代码。

#include <iostream>

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

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

并且代码仅在没有运行时异常的情况下运行!

输出为58

怎么可能?局部变量的存储不是在函数之外不可访问的吗?

标签:c++,memory-management,local-variables,dangling-pointer

回答1:

怎么可能?局部变量的存储不是在函数之外不可访问的吗?

您租了旅馆房间。您将一本书放在床头柜的顶部抽屉中,然后入睡。您第二天早上退房,但是"忘记了"退还您的钥匙。您偷了钥匙!

一周后,您返回酒店,不办理入住手续,用偷来的钥匙潜入您的旧房间,然后看着抽屉。你的书还在那里。令人惊讶!

那怎么可能?如果您尚未租用房间,不是不是无法进入酒店房间抽屉的物品吗?

好吧,很明显,这种情况可以在现实世界中发生,没有问题。当您不再被授权进入房间时,没有任何神秘的力量会使您的书消失。也没有一种神秘的力量阻止您使用被盗钥匙进入房间。

不需要 删除酒店的书。您没有与他们签订合同,说如果您留下东西,他们会为您切碎。如果您用偷来的钥匙非法重新进入房间以将其取回,则不会要求让酒店安全人员偷偷溜进去。您没有与他们订立合同,说"如果我稍后尝试再潜回我的房间,您必须阻止我。"相反,您与他们签订了一份合同,上面写着"我保证以后不会再潜入我的房间",这是您打破的合同。

在这种情况下任何事情都会发生。这本书可以在那里-您很幸运。可能有人的书在那里,而您的书可能在酒店的炉子里。当您进来时,有人可能会在那里,将您的书撕成碎片。该酒店本可以删除桌子并完全预订,然后用衣柜代替。整个酒店可能会被拆毁,取而代之的是一个足球场,而当您潜行时,您将在爆炸中丧生。

您不知道会发生什么;当您从酒店退房并偷走了以后非法使用的钥匙时,您放弃了生活在可预测的安全世界中的权利,因为选择了违反系统规则。

C ++不是安全的语言。它将乐意让您打破系统规则。如果您尝试做一些非法和愚蠢的事情,例如回到没有权限的房间,或者翻阅一张可能根本不在的桌子,那么C ++不会阻止您。比C ++更安全的语言通过限制您的力量来解决此问题-例如,通过对键进行更严格的控制。

更新

天哪,这个答案引起了很多关注。 (我不确定为什么-我认为这只是个"有趣"的小类比,但无论如何。)

我认为用一些更多的技术思想来对此进行更新可能是有道理的。

编译器负责生成代码,该代码管理该程序处理的数据的存储。生成代码以管理内存的方法有很多,但是随着时间的流逝,两种基本技术已经根深蒂固。

首先是要具有某种"长寿命"存储区,在该存储区中,存储区中每个字节的"寿命"(即与某个程序变量有效关联的时间段)不能为容易提前预测。编译器生成对"堆管理器"的调用,该堆管理器知道如何在需要时动态分配存储,并在不再需要时回收它。

第二种方法是拥有一个"短命"存储区,每个字节的生存期众所周知。在此,生命周期遵循"嵌套"模式。这些短期变量中寿命最长的变量将在任何其他短期变量之前分配,最后释放。寿命较短的变量将在寿命最长的变量之后分配,并在它们之前被释放。这些寿命较短的变量的寿命被"嵌套"在寿命较长的变量的寿命之内。

局部变量遵循后一种模式;输入方法后,其局部变量将生效。当该方法调用另一个方法时,新方法的局部变量将生效。在第一个方法的局部变量失效之前,它们将失效。可以提前确定与局部变量关联的存储生命周期的开始和结束的相对顺序。

由于这个原因,局部变量通常作为"堆栈"数据结构上的存储生成,因为堆栈具有将其压入的第一物将是最后弹出的属性。

这就像酒店决定只按顺序出租房间一样,只有在房间号高于您所选择的每个人之前,您都无法退房。

所以让我们考虑一下堆栈。在许多操作系统中,每个线程获得一个堆栈,并且该堆栈被分配为一定的固定大小。当您调用一个方法时,东西被压入堆栈。如果您随后将指针传递回方法之外的栈,就像原始海报在这里所做的那样,那只是指向某个完全有效的百万字节内存块中间的指针。打个比方,您从酒店退房;当您这样做时,您只是退出了编号最高的占用房间。如果没有其他人在您之后入住,并且您非法返回您的房间,则可以保证您所有的东西仍然在该特定酒店内。

我们将堆栈用于临时存储,因为它们确实便宜又容易。不需要使用C ++的实现就可以使用堆栈来存储本地对象。它可以使用堆。事实并非如此,因为那会使程序变慢。

不需要C ++的实现来使您留在堆栈上的垃圾保持不变,以便以后可以非法返回它;编译器生成将刚腾出的"房间"中的所有内容都归零的代码是完全合法的。并不是因为那又会很昂贵。

不需要C ++的实现来确保当堆栈在逻辑上收缩时,曾经有效的地址仍然映射到内存中。该实现被允许告诉操作系统"我们现在已经完成了该堆栈页面的使用。除非我另行声明,否则,如果有人触摸了先前有效的堆栈页面,则发出一个异常,该异常会破坏进程"。再次,实现实际上并没有这样做,因为它很慢且不必要。

相反,实现使您可以犯错误并摆脱错误。大多数时候。直到一天,真正可怕的事情出了问题,整个过程爆炸了。

这是有问题的。有很多规则,很容易意外地打破它们。我当然有很多次。更糟糕的是,问题通常只会在发生损坏后数十亿毫微秒内被检测到内存损坏时才出现,而这很难弄清是谁弄乱了内存。

更多的内存安全语言通过限制您的能力来解决此问题。在"普通" C#中,根本没有办法获取本地地址并将其返回或存储以供以后使用。您可以使用本地地址,但是语言设计巧妙,因此在本地生命周期结束后无法使用它。为了获取本地地址并将其传递回去,您必须将编译器置于特殊的"不安全"模式,在程序中放入" unsafe"一词,以引起注意您可能正在做一些危险的事情,可能会违反规则。

进一步阅读:

回答2:

您在这里所做的只是读取和写入用于作为a地址的内存。现在您不在foo之外,它只是指向某个随机内存区域的指针。碰巧的是,在您的示例中,该内存区域确实存在,并且目前没有其他人在使用它。您不会通过继续使用而破坏任何东西,并且还没有其他东西覆盖它。因此,5仍然存在。在真实的程序中,该内存将几乎立即被重新使用,并且这样做会破坏某些功能(尽管症状可能要等到很久以后才会出现!)

foo返回时,您告诉操作系统您不再使用该内存,可以将其重新分配给其他内存。如果您很幸运,但是它从未被重新分配过,并且操作系统没有抓住您再次使用它的机会,那么您就可以摆脱谎言。尽管您最终可能会写满以该地址结尾的任何内容。

现在,如果您想知道为什么编译器没有抱怨,那可能是因为foo被优化消除了。通常会警告您这种事情。 C假设您知道自己在做什么,并且从技术上讲,您在这里没有违反范围(在foo之外没有引用a本身),只有内存访问规则,它只会触发警告而不是错误。

简而言之:这通常不起作用,但有时会偶然。

回答3:

因为尚未进一步限制存储空间。不要指望这种行为。

回答4:

所有答案的补充:

如果您这样做:

#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()重用。如果您对可执行文件进行反汇编,则会清楚看到它。

回答5:

在C ++中,您可以访问任何地址,但这并不意味着您应该。您正在访问的地址不再有效。它之所以能够正常工作,是因为foo返回后,其他任何事情都不会扰乱内存,但是在许多情况下它可能会崩溃。尝试使用 Valgrind 分析程序,甚至只是对其进行优化编译,然后看...

回答6:

您永远不会通过访问无效的内存而引发C ++异常。您只是在举例说明引用任意内存位置的一般思路。我可以这样做:

unsigned int q = 123456;

*(double*)(q) = 1.2;

在这里,我只是将123456当作double的地址并将其写入。可能发生的任何事情:

    实际上,
  1. q实际上是双精度有效地址,例如doublep;q =&p;
  2. q可能指向分配的内存中的某个地方,我在那里覆盖了8个字节。
  3. q指向分配的内存之外,操作系统的内存管理器将分段错误信号发送到我的程序,从而导致运行时终止该程序。
  4. 您中了彩票。

设置方式将返回的地址指向内存的有效区域更为合理,因为它可能位于堆栈的更下方,但它仍然是无效位置,您不能确定性访问。

在正常程序执行过程中,没有人会像您那样自动检查内存地址的语义有效性。但是,内存调试器(例如valgrind)会很乐意这样做,因此您应该通过它运行程序并见证错误。

回答7:

您是否在启用优化程序的情况下编译程序? foo()函数非常简单,可能已内联或替换为结果代码。

但是我同意Mark B的观点,即行为是不确定的。

回答8:

您的问题与 scope 无关。在显示的代码中,函数main在函数foo中看不到名称,因此您不能直接在foo中访问afoo外使用 this 名称。

您遇到的问题是,为什么程序在引用非法内存时没有发出错误信号。这是因为C ++标准没有在非法内存和合法内存之间指定非常明确的界限。在弹出堆栈中引用某些内容有时会导致错误,有时则不会。这取决于。不要指望这种行为。假定在编程时它总是会导致错误,但假定在调试时它永远不会提示错误。

回答9:

您只是返回一个内存地址,它是允许的,但可能是错误。

是的,如果您尝试取消引用该内存地址,则将具有未定义的行为。

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
}

回答10:

正如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",但结果可能会有所不同(真的!)。您的指针正在破坏其他不相关的局部变量。

回答11:

请注意所有警告。不仅解决错误。
GCC显示此警告

警告:返回了本地变量'a'的地址

这是C ++的强大功能。您应该关心内存。使用-Werror标志,此警告变为错误,现在您必须对其进行调试。

回答12:

之所以能够工作,是因为自从将a放入堆栈以来,堆栈还没有被更改。再次访问a之前,请调用其他一些函数(这些函数也正在调用其他函数),您可能再也不会如此幸运了;;-)

回答13:

这是经典的不确定的行为,我们已经在两天前进行了讨论-在网站上进行搜索。简而言之,您很幸运,但是任何事情都可能发生,并且您的代码使对内存的访问无效。

回答14:

您实际上调用了未定义的行为。

返回临时作品的地址,但是由于临时元素在函数末尾被销毁,因此访问它们的结果将是不确定的。

所以您没有修改a,而是修改了a曾经的存储位置。这种差异与崩溃与不崩溃之间的差异非常相似。

回答15:

在典型的编译器实现中,您可以将代码认为是"打印出地址内存块的值,该地址以前被a占用"。另外,如果您向包含本地int的函数添加新的函数调用,则很有可能a的值(或a指向)更改。发生这种情况是因为堆栈将被包含不同数据的新帧覆盖。

但是,这是未定义行为,您不应依靠它来工作!

回答16:

它可以,因为a是在其作用域的生存期内临时分配的变量(foo函数)。从foo返回后,内存是可用的并且可以被覆盖。

您正在做的事情被描述为未定义的行为。结果无法预测。

回答17:

如果使用:: 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); 
}

回答18:

从函数返回后,所有标识符都会被破坏,而不是将值保留在内存位置中,并且我们无法在没有标识符的情况下定位这些值。但是该位置仍然包含先前函数存储的值。

因此,此处的函数foo()返回的是a的地址,而a返回其地址后将被销毁。您可以通过返回的地址访问修改后的值。

让我举一个真实的例子:

假设某人将钱藏在某个地点,然后告诉您该地点。一段时间后,告诉您钱款地点的那个人去世了。但是您仍然可以使用这些隐藏的资金。

回答19:

这是使用内存地址的"肮脏"方式。返回地址(指针)时,您不知道该地址是否属于函数的本地范围。这只是一个地址。既然您已经调用了'foo'函数,那么'a'的地址(内存位置)已经被分配到了应用程序(进程)的(至少现在是安全的)可寻址内存中。返回'foo'函数后,'a'的地址可以被认为是'dirty',但它在那里,没有被清理,也没有被程序其他部分的表达式所干扰/修改(至少在这种情况下)。 C / C ++编译器不会阻止您进行此类"肮脏"访问(不过,如果您愿意的话,可能会警告您)。除非通过某种方式保护地址,否则您可以安全地使用(更新)程序实例(进程)的数据段中的任何内存位置。

回答20:

您的代码非常危险。您正在创建一个局部变量(在函数结束后将其视为销毁),并在对该变量进行销毁后返回该内存的地址。

这意味着内存地址可能有效或无效,并且您的代码将容易受到可能的内存地址问题(例如分段错误)的影响。

这意味着您在做一件非常糟糕的事情,因为您根本无法信任将内存地址传递给一个指针。

请考虑以下示例,并对其进行测试:

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分配内存到本地函数
  • 当功能到期时(该地址未被任何人删除),该内存地址也仍然有效
  • 内存地址是可信任的(该内存块不被认为是空闲的,因此在删除之前不会覆盖它)
  • 不使用时应删除内存地址。 (请参阅程序末尾的删除)
回到顶部