C 程序员应该知道的未定义行为 #3/3

为什么基于未定义行为优化时无法发出警告？

float *P;
 void zero_array() {
   int i;
   for (i = 0; i < 10000; ++i)
     P[i] = 0.0f;
}

警告：经过 3 级内联（可能跨越文件，使用链接时优化），一些公共子表达式消除，在将此项提升到循环之外并证明这 13 个指针不重叠之后，我们发现了一个你执行了未定义操作的情况。这可能是因为你的代码中存在错误，也可能是因为你使用了宏和内联，并且无效代码在动态上不可达，但我们无法证明它是死代码。

Clang 处理未定义行为的方法

1. 如果有一种好的方法，未定义行为的某些情况会被静默地转换为隐式陷阱操作。例如，使用 Clang，以下 C++ 函数
   
   

   int *foo(long x) {
     return new int[x];
   }
   

   
   编译成以下 X86-64 机器代码
   
   

   __Z3fool:
           movl $4, %ecx
           movq %rdi, %rax
           mulq %rcx
           movq $-1, %rdi        # Set the size to -1 on overflow
           cmovnoq %rax, %rdi    # Which causes 'new' to throw std::bad_alloc
           jmp __Znam
   

   
   而不是 GCC 生成的代码
   
   

   __Z3fool:
           salq $2, %rdi
           jmp __Znam             # Security bug on overflow!
   

   
   这里不同的是，我们决定投入一些周期来防止可能出现的 严重的整数溢出错误，这种错误会导致缓冲区溢出和漏洞利用（operator new 通常相当昂贵，因此开销几乎不会被注意到）。GCC 的开发人员已经 至少从 2005 年开始就意识到这个问题了，但在撰写本文时还没有修复它。
2. 在 对未定义值进行运算 的算术运算被认为会产生一个未定义值，而不是产生未定义行为。区别在于，未定义值不会格式化你的硬盘驱动器或产生其他不良影响。当算术运算在任何可能的未定义值的实例下都会产生相同的输出位时，会发生一个有用的改进。例如，优化器假设“undef & 1”的结果的高位为零，仅将低位视为未定义。这意味着 ((undef & 1) >> 1) 在 LLVM 中被定义为 0，而不是未定义。
3. 动态执行未定义操作（例如带符号整数溢出）的算术运算会生成一个逻辑 陷阱值，该值会破坏基于它的任何计算，但不会破坏你的整个程序。这意味着未定义操作下游的逻辑可能会受到影响，但你的整个程序不会被破坏。这就是为什么优化器最终会删除对未初始化变量进行操作的代码，例如。
4. 对空值的存储和通过空指针调用会被转换为 __builtin_trap() 调用（在 x86 上会转换为像“ud2”这样的陷阱指令）。这些操作在优化代码中经常出现（作为内联和常量传播等其他转换的结果），我们以前只是删除包含它们的代码块，因为它们“显然不可达”。
   
   虽然（从迂腐的语言律师的角度来看）这是严格正确的，但我们很快发现人们偶尔会解引用空指针，并且让代码执行只是落入下一个函数的顶部，会让问题难以理解。从性能的角度来看，暴露这些操作的最重要方面是压制下游代码。因此，clang 将它们转换为运行时陷阱：如果其中一个操作实际上被动态地到达，程序会立即停止并可以进行调试。这样做的缺点是我们稍微增加了代码的膨胀，因为有了这些操作以及控制它们谓词的条件。
5. 优化器确实会尽力“做正确的事情”，当程序员的意图很明显时（例如，代码执行“*(int*)P”时，P 是指向浮点数的指针）。这在许多常见情况下都有帮助，但你真的不应该依赖它，而且有很多你可能认为是“显而易见”的例子，但在对你的代码应用了一系列转换之后就不再是“显而易见”的了。
6. 不属于任何这些类别的优化，例如第 1 部分中的 zero_array 和 set/call 示例，会像描述的那样进行优化，即静默地进行，没有任何提示给用户。我们这样做是因为我们没有有用的信息要提供，而且对于（有错误的）现实世界代码来说，被这些优化破坏的情况非常罕见。

使用更安全的 C 语言方言（和其他选项）