clang++ 9.0 如何神奇地治愈 lambda 中的悬空引用使用?

How does clang++ 9.0 magically cure dangling reference use in a lambda?

本文关键字:lambda 引用 何神奇 神奇 clang++      更新时间:2023-10-16

我在wandbox上做实验,希望找到编译器警告,这将有助于在lambda中无意中悬空引用。我有这个以多种方式行为不端的例子:

std::array<std::function<const int *(void)>,N> createFunctions()
{
std::array<std::function<const int *(void)>,N> fns;
for ( int i = 0 ; i < N ; i++ ) {
std::cout << &i << " ";
fns[i] = [&]() {
return &i;
};
}
std::cout << "n";
return fns;
}

这会将一组 lambda 填充到函数数组中。每个 lambda 返回一个指针,指向对捕获变量的引用,i。周围应该很麻烦。

我的驱动程序例程打印出指针,并取消引用它。

int main()
{
auto fns = createFunctions();
for (int j = 0 ; j < N ; j++ ) {
if (j != 0)
std::cout << ", ";
std::cout << fns[j]() << ": " << *fns[j]();
}
std::cout << "n";
return 0;
}

如果将此 lambda 修改为通过复制传递i,您将获得如下输出 - 四个指针和四个具有唯一值的指针:

0x7ffc80e65358 0x7ffc80e65358 0x7ffc80e65358 0x7ffc80e65358 
0x7ffc80e65380: 0, 0x7ffc80e653a0: 1, 0x7ffc80e653c0: 2, 0x7ffc80e653e0: 3

当它写错时,取一个无声地超出范围的引用,它奇迹般地运行而没有出错,但清楚地显示了它的方式错误

0x7ffeebdfe9f4 0x7ffeebdfe9f4 0x7ffeebdfe9f4 0x7ffeebdfe9f4 
0x7ffeebdfe9f4: 32766, 0x7ffeebdfe9f4: 32766, 0x7ffeebdfe9f4: 32766, 0x7ffeebdfe9f4: 32766

所有四个指针都是相同的,并且它们指向的值是虚假的。

所有版本的 g++ 以及 8.x 之前的所有 clang++ 版本都是如此。但是 clang 9.0 奇迹般地以一种神奇的方式处理了它:

0x7ffd193bfa30 0x7ffd193bfa30 0x7ffd193bfa30 0x7ffd193bfa30 
0x7ffd193bfa30: 0, 0x7ffd193bfa30: 1, 0x7ffd193bfa30: 2, 0x7ffd193bfa30: 3

真正有趣的是,指向引用的指针在所有四个 lambda 中都具有相同的值 - 但取消引用它们会返回四个不同的值。我试图想出一个很好的解释,解释这是怎么回事,但我被难住了。

我猜这是一种有意的优化,编译器已经推断出我想做什么,并让它发生。由于使用悬空引用属于"未定义行为"类别,因此编译器可以自由地做它喜欢的事情。但事实果真如此吗?

如果编译器足够聪明来解决这个问题,那么它似乎足够聪明,可以发出警告,但我不明白。

根据评论列车,特别是@RaymondChen的评论,很明显 clang没有解决这个问题。生成的代码使它看起来像是他们修复了它,但这只是一些非常偶然的未定义行为。

几乎 100% 确定,我们可以这样说:

  • lambda函数创建了一个对变量i的悬空引用,一个在使用lambda之前从堆栈中消失的自动。
  • 然后调用lambda指向堆栈上或周围的随机数据,其值可以是任何内容。
  • 在大多数实现中,所指向的值显然不是所期望的。
  • 幸运的是,在 clang 9 中,悬空的引用指针指向循环变量j,它在范围内,并且从 0 迭代到 3,看起来好像我们以某种方式拥有悬空引用的良好副本。

更改main()中的循环以迭代 lambda 引用,如下所示:

for (auto fn: fns ) {

消除了循环变量 j,因此现在输出为:

0x7ffc0f21a100 0x7ffc0f21a100 0x7ffc0f21a100 0x7ffc0f21a100 
0x7ffc0f21a100: 4212390, 0x7ffc0f21a100: 4212390, 0x7ffc0f21a100: 4212390, 0x7ffc0f21a100: 4212390

仍然在寻找检测这种编程错误的好方法,这为我们提供了人类永恒警惕的辅助手段。赫伯·萨特(Herb Sutter(的终身档案将是一个很好的方法,如果它发生的话。