GCC 6有一项新的优化器特性：它假设this总是非空并基于此进行优化。
值范围传播现在假定C++成员函数的this指针是非空的。这消除了常见的空指针检查但也破坏了一些不符合规范的代码库（例如Qt-5、Chromium、KDevelop）。可以使用-fno-delete-null-pointer-checks作为临时解决方法。可以通过使用-fsanitize=undefined来确定错误代码。
更改文档明确指出这是危险的，因为它破坏了惊人数量的经常使用的代码。
为什么这个新的假设会破坏实际的C++代码？是否有特定的模式，粗心或无知的程序员依赖于这种特定的未定义行为？我无法想象任何人会写if (this == NULL)，因为那太不自然了。
我想需要回答的问题是，为什么有善意的人一开始就会写支票。
最常见的情况可能是您有一个类，它是自然递归调用的一部分。
如果您有：
struct Node
{
Node* left;
Node* right;
};
在C语言中，你可能会这样写：
void traverse_in_order(Node* n) {
if(!n) return;
traverse_in_order(n->left);
process(n);
traverse_in_order(n->right);
}
在C++中，将此函数作为成员函数是很好的选择：
void Node::traverse_in_order() {
// <--- What check should be put here?
left->traverse_in_order();
process();
right->traverse_in_order();
}
this 的函数的语法糖。代码会先用C++编写，然后转换为等效的C代码并进行编译。甚至有明确的示例表明将 this 与 null 进行比较是有意义的，最初的 Cfront 编译器也利用了这一点。因此，对于检查来说，从 C 背景出发，显而易见的选择是：if(this == nullptr) return;
注意：Bjarne Stroustrup甚至提到了多年来this的规则已经发生了变化，可以在此处找到相关信息。
这个问题在许多编译器上工作了很多年。当标准化发生时，这种情况就改变了。最近，编译器开始利用调用成员函数的优势，其中this为空指针是未定义行为，这意味着这个条件总是false，编译器可以省略它。
这意味着要遍历这个树，你需要做以下两件事之一：
在调用traverse_in_order之前进行所有的检查
void Node::traverse_in_order() {
if(left) left->traverse_in_order();
process();
if(right) right->traverse_in_order();
}
这也意味着需要在每个调用点检查是否存在空根节点。
不要使用成员函数。
这意味着您正在编写旧的C风格代码（可能是静态方法），并在显式将对象作为参数传递的情况下调用它。例如，您回到了在调用点编写 Node::traverse_in_order(node); 而不是 node->traverse_in_order(); 的方式。
我认为在符合标准的情况下修复此特定示例最简单/最整洁的方法实际上是使用哨兵节点而不是nullptr。
// static class, or global variable
Node sentinel;
void Node::traverse_in_order() {
if(this == &sentinel) return;
...
}
前两个选项都不太吸引人，虽然代码可以通过，但他们写了糟糕的代码，使用了this == nullptr 而不是使用适当的修复方法。
我猜这就是一些代码库演化到其中包含 this == nullptr 检查的原因。
1 == 0 可能是未定义行为？它只是简单地被判定为 false。 - Johannes Schaub - litbthis == nullptr惯用语是未定义行为，因为在此之前你已经调用了一个空指针对象的成员函数，这是未定义的。而编译器有权省略检查。 - jtlimthis可能为空。我想这可能是在SO存在的年代学习C++的好处之一，它巩固了UB的危害并阻止我像这样做奇怪的技巧。 - underscore_dthis。this转换为非空的。因此，至少应该将方法应该与空的this一起工作的类设置为最终类，没有基类：它不能派生任何东西，也不能被派生。我们很快就会从实际到丑陋的hack地带。struct Node
{
Node* left;
Node* right;
void process();
void traverse_in_order() {
traverse_in_order_impl(this);
}
private:
static void traverse_in_order_impl(Node * n)
if (!n) return;
traverse_in_order_impl(n->left);
n->process();
traverse_in_order_impl(n->right);
}
};
this检查问题，因此不需要人工逐个搜索。这个补丁可能只需要几百行简单的更改。 - Kuba hasn't forgotten Monicathis 解引用会导致立即崩溃。即使没有人运行静态分析器检查代码，这些问题也很快就会被发现。C/C++ 遵循“只为所需功能付费”的信条。如果您想要检查，必须明确指定，这意味着不能在 this 上进行检查，因为编译器假定 this 不为 null，当时已经太晚了。否则，它将不得不检查 this，而对于99.9999%的代码来说，这样的检查是浪费时间。 - Kuba hasn't forgotten Monica更改文档明确指出这是危险的，因为它会破坏相当多经常使用的代码。
这份文档并没有称之为危险。也没有声称它会破坏“相当多的代码”。它只是指出了一些广泛使用的代码库，据称已知依赖于该未定义行为，并且如果不使用解决方法选项，则会因更改而中断。
为什么这种新的假设会破坏实用的C ++代码？
如果“实用”的C ++代码依赖于未定义的行为，那么对该未定义行为进行更改可能会破坏它。这就是为什么应该避免UB，即使依赖它的程序似乎按预期工作。
是否存在特定模式，其中粗心或无知的程序员依赖于这种特定的未定义行为？
我不知道这是否是一种普遍的反模式，但一个无知的程序员可能会认为他们可以通过以下方式修复程序不崩溃：
if (this)
member_variable = 42;
当实际的错误是在其他地方取消引用空指针时。
我相信，如果程序员不够了解情况，他们将能够提出更高级（反）模式，这些模式依赖于这种未定义行为。
我无法想象任何人会编写
if (this == NULL)，因为那是非常不自然的。
但我可以。
-fsanitize=null是否可将错误记录到SD / MMC卡上，使用SPI针脚＃5,6,10,11？但这不是一种通用解决方案。一些人认为，访问空对象违反了面向对象的原则，然而一些OOP语言有一个可以操作的空对象，因此这不是OOP的通用规则。1/2 - Stephane Hockenhull一些“实用”的（拼写成“buggy”的有趣方式）破损代码看起来像这样：
void foo(X* p) {
p->bar()->baz();
}
它忘记考虑到p->bar()有时会返回空指针，这意味着对其进行解引用调用baz()是未定义的。
并非所有出现问题的代码都包含明确的if (this == nullptr)或if (!p) return;检查。有些情况只是一些没有访问任何成员变量的函数，因此看起来运行良好。例如：
struct DummyImpl {
bool valid() const { return false; }
int m_data;
};
struct RealImpl {
bool valid() const { return m_valid; }
bool m_valid;
int m_data;
};
template<typename T>
void do_something_else(T* p) {
if (p) {
use(p->m_data);
}
}
template<typename T>
void func(T* p) {
if (p->valid())
do_something(p);
else
do_something_else(p);
}
func<DummyImpl*>(DummyImpl*)时，会进行一个“概念性”的指针解引用来调用p->DummyImpl::valid()，但实际上该成员函数只返回false而不访问*this。这个return false可以被内联，因此在实践中指针根本不需要被访问。因此，在某些编译器中，它似乎正常工作：对空指针进行解引用不会导致段错误，p->valid()是false，所以代码调用do_something_else(p)，它检查空指针，因此什么也不做。没有观察到崩溃或意外行为。p->valid()的调用，但编译器现在从该表达式推断出p必须是非空的（否则p->valid()将是未定义行为），并记录下这些信息。优化器使用推断出的信息，因此如果调用do_something_else(p)被内联，那么if (p)检查现在被认为是多余的，因为编译器记得它不是空的，所以内联代码变成了：template<typename T>
void func(T* p) {
if (p->valid())
do_something(p);
else {
// inlined body of do_something_else(p) with value propagation
// optimization performed to remove null check.
use(p->m_data);
}
}
现在这个指针真的被取消引用了，因此之前看起来能工作的代码停止工作。
在这个例子中，bug 在func函数中，其应该首先检查是否为null（或者调用方不应该使用null调用它）：
template<typename T>
void func(T* p) {
if (p && p->valid())
do_something(p);
else
do_something_else(p);
}
this 与空值进行比较"? - T.C.this的无效使用等各种类型的UB，则只需使用 -fsanitize=undefined。 - Jonathan Wakelyif(!this) 或 (this == 0) 等。是否有可能让编译器（GCC 6）在遇到这样的代码时发出警告？这可能有助于修复有缺陷的代码的 努力。 - jotikC++标准在重要方面存在缺陷。不幸的是，GCC开发人员选择使用未定义行为作为实现边缘优化的借口，而不是保护用户免受这些问题的影响，即使已经清楚地向他们解释了其有害性。
这里有一个比我聪明得多的人详细解释了这个问题。（他谈论的是C语言，但情况在这里是相同的）。
简单地使用更新版本的编译器重新编译以前正常、安全的代码可能会引入安全漏洞。虽然新行为可以通过某个标志位禁用，但现有的 makefile 没有设置该标志位。由于没有警告提示，开发者不会意识到以前合理的行为已经被更改。
在本示例中，开发者使用了 assert 进行整数溢出检查，如果提供了无效的长度，则程序将终止运行。GCC 团队移除了这个检查，因为整数溢出是未定义的，因此可以移除该检查。这导致实际的代码库在修复问题后再次变得容易受攻击。
请认真阅读整个内容。它足以让你热泪盈眶。
很久以前，有一个相当常见的习语，大概是这样的：
OPAQUEHANDLE ObjectType::GetHandle(){
if(this==NULL)return DEFAULTHANDLE;
return mHandle;
}
void DoThing(ObjectType* pObj){
osfunction(pObj->GetHandle(), "BLAH");
}
所以这个习惯用法是：如果pObj不为空，你使用它包含的句柄，否则你使用默认句柄。这被封装在GetHandle函数中。
诀窍在于调用非虚函数实际上并没有使用this指针，因此没有访问冲突。
有很多代码都是这样写的。如果有人只是重新编译它而没有改变一行代码，那么每次调用DoThing(NULL)都会导致崩溃 - 如果你幸运的话。
如果你不幸运，崩溃漏洞就会变成远程执行漏洞。
这甚至可以自动发生。你有一个自动构建系统，对吧？升级到最新的编译器是无害的，对吧？但现在不是了 - 如果你的编译器是GCC。
他们已经被告知了。他们完全知道后果。
谁能说呢？也许：
或者也许是其他什么。谁能说呢？
this作为隐式参数的事实，因此他们开始像使用显式参数一样使用它。但实际上并不是这样。当你对一个空指针的this进行解引用时，你将会像对其他任何空指针一样触发未定义行为。就是这样简单。如果想要传递nullptr，请使用显式参数，傻瓜。它不会更慢，不会更笨重，并且具有此类API的代码深入内部，因此范围非常有限。故事结束。 - Kuba hasn't forgotten Monica