为什么增强的GCC6优化器会破坏实用的C++代码？

Question

GCC6有一个新的优化器特性：它假设this总是不为空，并基于此进行优化。

值范围传播现在假定C++成员函数的this指针是非空的。这消除了常见的空指针检查，但也破坏了一些不一致的代码基（如Qt-5、Chromium、KDevelop)。作为临时解决办法，可以使用-fno-delete-null-pointer-checks。使用-fsanitize=undefined可以识别错误的代码。

变更文档明确指出这是危险的，因为它破坏了数量惊人的频繁使用的代码。

为什么这个新的假设会破坏实际的C++代码？是否有一些特定的模式，让粗心或不知情的程序员依赖于这种特定的未定义的行为？我无法想象有人会在（this==NULL)的情况下编写，因为这太不自然了。




Answer 1

我想一个需要回答的问题是为什么好心的人会首先开出支票。

最常见的情况可能是，如果您有一个类是自然发生的递归调用的一部分。

如果你有：

struct Node
{
    Node* left;
    Node* right;
};

void traverse_in_order(Node* n) {
    if(!n) return;
    traverse_in_order(n->left);
    process(n);
    traverse_in_order(n->right);
}

void Node::traverse_in_order() {
    // <--- What check should be put here?
    left->traverse_in_order();
    process();
    right->traverse_in_order();
}

在C++早期（标准化之前），强调成员函数是函数的语法糖，其中this参数是隐式的。代码是用C++编写的，转换成等效的C并进行编译。甚至有明确的例子表明，将this与null进行比较是有意义的，原始的Cfront编译器也利用了这一点。因此，从C背景来看，检查的明显选择是：

if(this == nullptr) return;      

注意：Bjarne Stroustrup甚至提到this的规则多年来在这里发生了变化

这在许多编译器上工作了很多年。当标准化发生时，这就改变了。最近，编译器开始利用调用成员函数的优势，其中this为nullptr是未定义的行为，这意味着该条件始终为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检查的原因。