由于可能undefined behavior，在实际加/减之前检测整数溢出有很多问题。所以，我的问题是
为什么它首先会产生这个undefined behavior？
我能想到两个原因：
1) 在这种情况下产生异常的处理器。当然，它可以被关闭，而且很可能一个写得很好的 CRT 可以做到这一点。
2) 使用其他二进制数字表示的处理器（1 的补码？以 10 为底？）。在这种情况下，未定义的行为将表现为不同的结果（但不会崩溃！）。好吧，我们可以忍受。
那么，为什么有人要避免引起它呢？我错过了什么吗？
【问题讨论】：
标签： c
虽然有符号溢出被指定为未定义行为的历史原因可能是这些虚假的遗留表示（补码/符号大小）和溢出中断，但它保持未定义行为的现代原因是优化。正如 J-16 SDiZ 所暗示的那样，有符号溢出是未定义行为这一事实允许编译器优化其代数真值（但不一定是表示级真值）已由前一个分支建立的一些条件。如果子表达式包含溢出，它还可以允许编译器以代数方式简化某些表达式（尤其是那些涉及乘法或除法的表达式），从而产生与最初编写的求值顺序不同的结果，因为允许编译器假设溢出你给它的操作数不会发生。
为了允许优化而未定义行为的另一个重要例子是别名规则。
【讨论】：
虽然大多数现代 CPU 使用 2 的补码，并且整数溢出会导致可预测的模回绕，但这绝不是通用的 - 以保持语言足够通用以使其可以在最广泛的范围内使用架构最好指定整数溢出为 UB。
【讨论】：
x<-1 需要 2 次机器级比较而不是 1 次），但我仍然更喜欢这种方式。
规范中的undefined behavior 位涉及一些编译器优化。例如：
if (a > 0 && b > 0) {
if ( a + b <= 0 ) {
// this branch may be optimized out by compiler
} else {
// this branch will always run
}
}
现代 C 编译器并不是那么简单，它会进行大量的猜测和优化。
【讨论】：
volatile。
volatile 关键字的有效使用。如果它有效，它是特定实现的结果，而不是特定行为。 IE。它仍然是未定义的行为。
int 的范围，则可以实现此类优化而不需要整数溢出为未定义行为具有算术正确的结果 mod (2*INT_MAX+2)，并且如果将这样的值存储到 int 变量中，则对该变量的任何读取都可以独立地表现为任何具有相同一致性的任意数学整数班级。这样的规则将允许许多有用的优化，并且也适合常见的执行模型......
int 长。事实上，如果我有我的 druthers，我会为这些值定义一个标准术语“部分不确定”，并指定一个实现可以将超出范围的有符号整数向下转换的行为定义为产生一个部分不确定的值。否则，当与 int 大小不符合预期的机器一起使用时，uint32_t 之类的类型很容易产生 UB。
我认为您的假设 1) 如果我的记忆正确的话，至少在一个重要的历史架构 CDC 上，可以为任何给定处理器关闭此功能是错误的。
【讨论】：
#ifdef 处理这些情况。
#ifdef 只是避免 UB 的一种方法。但是你看，正如你自己所说，你会以某种方式处理这个问题。