在循环中的什么时候整数溢出会变成未定义的行为？

这是一个示例来说明我的问题，其中涉及一些我无法在此处发布的更复杂的代码。

#include <stdio.h>
int main()
{
    int a = 0;
    for (int i = 0; i < 3; i++)
    {
        printf("Hello\n");
        a = a + 1000000000;
    }
}

该程序在我的平台上包含未定义的行为，因为a它将在第3个循环中溢出。

这是否会使整个程序具有未定义的行为，还是仅在实际发生溢出之后？编译器是否可以解决a 将导致溢出的问题，以便它可以声明整个循环未定义，并且即使它们都在溢出之前发生，也不必费心运行printfs？

_{（尽管标记为C和C ++有所不同，但如果它们不相同，我会对两种语言的答案都感兴趣。）}

如果您对纯粹的理论答案感兴趣，则C ++标准允许使用未定义的行为进行“时间旅行”：

[intro.execution]/5: 执行格式正确的程序的合格实现应产生与具有相同程序和相同输入的抽象机相应实例的可能执行之一相同的可观察行为。但是，如果任何这样的执行包含未定义的操作，则此国际标准对使用该输入执行该程序的实现没有任何要求（即使对于第一个未定义的操作之前的操作也没有要求）

这样，如果您的程序包含未定义的行为，则整个程序的行为将是未定义的。

首先，让我更正这个问题的标题：

未定义行为不是（特别是）执行领域。

未定义行为会影响所有步骤：编译，链接，加载和执行。

请记住一些示例，以确保这一点：

• 编译器可以假定从未执行包含未定义行为的代码部分，因此假定导致它们的执行路径为无效代码。请参阅克里斯·拉特纳（Chris Lattner），每个C程序员应该了解的未定义行为。
• 链接器可以假定存在一个弱符号（通过名称识别）的多个定义时，由于一个定义规则，所有定义都是相同的
• 加载程序（如果使用动态库的话）可以假定相同，从而选择它找到的第一个符号；通常用于LD_PRELOAD在Unixes上使用技巧来拦截呼叫
• 如果您使用悬空指针，执行可能会失败（SIGSEV）

这就是未定义行为的可怕之处：几乎不可能提前预测会发生什么确切的行为，并且每次工具链，底层操作系统更新时都必须重新考虑这种预测。

我建议观看Michael Spencer（LLVM开发人员）的这段视频：CppCon 2016：My Little Optimizer：Undefined Behavior is Magic。

积极地针对16位的C或C ++编译器int将知道添加1000000000到int类型的行为是不确定的。

它是由两种标准允许做任何它想做这可能包括整个程序的缺失，留下int main(){}。

但是更大的呢 ints呢？我还不知道执行此操作的编译器（无论如何我都不是C和C ++编译器设计的专家），但是我想有时候某个面向32位int或更高版本的编译器会发现该循环是无限的（i不会改变），因此a最终会溢出。因此，它可以再次将输出优化为int main(){}。我在这里要说明的一点是，随着编译器优化逐渐变得更加积极，越来越多的未定义行为构造以意想不到的方式表现出来。

循环无限的事实本身并不是不确定的，因为您正在循环主体中写入标准输出。

从技术上讲，在C ++标准下，如果程序包含未定义的行为，则即使在编译时（甚至在程序执行之前），整个程序的行为也是未定义的。

在实践中，由于编译器可能会（作为优化的一部分）假定不会发生溢出，因此尽管在循环的第三次迭代（假设是32位计算机）上，至少程序的行为是不确定的您可能会在第三次迭代之前获得正确的结果。但是，由于整个程序的行为在技术上是不确定的，因此无法阻止该程序生成完全不正确的输出（包括无输出），在运行期间的任何时候在运行时崩溃，甚至无法完全编译（因为未定义的行为会扩展到编译时间）。

未定义行为为编译器提供了更多优化空间，因为它们消除了有关代码必须执行的某些假设。这样做不能保证依赖于涉及未定义行为的假设的程序可以按预期工作。因此，您不应依赖C ++标准认为未定义的任何特定行为。

要了解为什么未定义的行为可以像@TartanLlama那样恰当地“时间旅行”，让我们看一下“假设”规则：

1.9程序执行

¹本国际标准中的语义描述定义了参数化的不确定性抽象机器。本国际标准对一致性实现的结构没有要求。特别是，它们不需要复制或模拟抽象机的结构。相反，需要遵循的实现来（仅）模拟抽象机的可观察行为，如下所述。

这样，我们可以将程序视为带有输入和输出的“黑匣子”。输入可以是用户输入，文件和许多其他内容。输出是标准中提到的“可观察到的行为”。

该标准仅定义了输入和输出之间的映射，没有别的。它通过描述一个“示例黑匣子”来做到这一点，但明确表示具有相同映射的任何其他黑匣子同样有效。这意味着黑匣子的内容无关紧要。

考虑到这一点，说不确定的行为在某个时刻发生是没有意义的。在黑匣子的示例实现中，我们可以说出发生的时间和地点，但是实际黑匣子可能完全不同，因此我们无法再说出它在何时何地发生。从理论上讲，编译器可以例如决定枚举所有可能的输入，并预先计算结果输出。这样，未定义的行为将在编译期间发生。

未定义的行为是输入和输出之间的映射不存在。对于某些输入，程序可以具有未定义的行为，而对于其他输入，则可以具有定义的行为。这样，输入和输出之间的映射就是不完整的。存在没有映射到输出的输入。
问题中的程序对于任何输入都具有未定义的行为，因此映射为空。

假设int是32位，则在第三次迭代时发生未定义的行为。因此，例如，如果循环仅在第三次迭代之前有条件地达到或可以有条件地终止，那么除非实际到达第三次迭代，否则就不会有未定义的行为。但是，如果行为未定义，则程序的所有输出都是不确定的，包括相对于调用未定义行为而言“过去”的输出。例如，对于您而言，这意味着不能保证在输出中看到3条“ Hello”消息。

TartanLlama的答案是正确的。未定义的行为可能随时发生，即使在编译期间也可能发生。这似乎很荒谬，但这是允许编译器执行所需操作的关键功能。成为编译器并不总是那么容易。您必须每次都严格按照规范的要求进行操作。但是，有时很难证明正在发生某种特定行为。如果您还记得停顿问题，那么在开发软件时就显得微不足道了，您无法证明该问题在馈入特定输入后是否完成或进入无限循环。

我们可能会使编译器变得悲观，并在担心下一条指令可能是诸如问题之类的停顿问题之一的情况下不断进行编译，但这是不合理的。相反，我们让编译器通过了：在这些“未定义的行为”主题上，它们没有任何责任。未定义的行为包含所有如此微妙的行为，以至于我们很难将它们与真正令人讨厌的停止问题隔离开来。

有一个我喜欢发布的示例，尽管我承认我失去了来源，所以我必须换个说法。它来自特定版本的MySQL。在MySQL中，它们有一个循环缓冲区，其中填充了用户提供的数据。他们当然想确保数据不会溢出缓冲区，所以他们进行了检查：

if (currentPtr + numberOfNewChars > endOfBufferPtr) { doOverflowLogic(); }

看起来足够理智。但是，如果numberOfNewChars确实很大并且溢出怎么办？然后它环绕并变成小于的指针endOfBufferPtr，因此永远不会调用溢出逻辑。因此，他们在此之前添加了第二项检查：

if (currentPtr + numberOfNewChars < currentPtr) { detectWrapAround(); }

看起来您已经处理了缓冲区溢出错误，对吗？但是，提交了一个错误，指出该缓冲区在特定版本的Debian上溢出了！仔细的调查表明，此版本的Debian是第一个使用特别先进的gcc版本的版本。在此版本的gcc上，编译器认识到currentPtr + numberOfNewChars永远不能小于currentPtr，因为指针的溢出是未定义的行为！这足以使gcc优化整个检查，并且即使您编写了代码来检查它，突然间您也无法防止缓冲区溢出！

这是规范行为。一切都是合法的（尽管据我所知，gcc在下一版本中回滚了此更改）。这不是我认为的直观行为，但是如果您稍加扩展想象力，就很容易看到这种情况的微小变化如何可能会成为编译器的停顿问题。因此，规范编写者将其定义为“未定义行为”，并表示编译器可以绝对满足其要求。

除了理论上的答案外，一个实践的观察是，很长一段时间以来，编译器已经对循环进行了各种变换，以减少循环中的工作量。例如，给定：

for (int i=0; i<n; i++)
  foo[i] = i*scale;

编译器可能会将其转换为：

int temp = 0;
for (int i=0; i<n; i++)
{
  foo[i] = temp;
  temp+=scale;
}

从而节省了每次循环迭代的乘法。编译器以不同程度的攻击性进行了调整的另一种优化形式会将其转化为：

if (n > 0)
{
  int temp1 = n*scale;
  int *temp2 = foo;
  do
  {
    temp1 -= scale;
    *temp2++ = temp1;
  } while(temp1);
}

即使在溢出时进行静默环绕的机器上，如果小于n的某个数也可能会发生故障，将其乘以小数会产生0。如果从内存中多次读取了小数位，也可能会陷入无尽的循环。意外更改了它的值（在任何情况下，如果“ scale”可以在不调用UB的情况下更改中间循环，则不允许编译器执行优化）。

尽管在将两个短无符号类型相乘以得到介于INT_MAX + 1和UINT_MAX之间的值的情况下，大多数此类优化不会有任何麻烦，但是gcc在某些情况下，循环内的这种相乘可能会导致循环提早退出。 。我没有注意到这种行为是由生成的代码中的比较指令引起的，但是在编译器使用溢出来推断循环最多可以执行4次或更少的情况下，这种现象是可以观察到的。在某些输入会导致UB而其他输入不会导致UB的情况下，即使它的推断导致忽略了循环的上限，它也不会默认生成警告。

根据定义，未定义的行为是灰色区域。您根本无法预测它将做什么或将不会做什么-这就是“未定义的行为”的含义。

自远古时代以来，程序员就一直试图从不确定的情况中挽救确定性的残余。他们有一些他们真正想要使用的代码，但是结果却是不确定的，所以他们试图争辩：“我知道它是未定义的，但是肯定会在最坏的情况下执行此或该操作；它将永远不会这样做。。” 有时这些论点或多或少是正确的-但通常，它们是错误的。随着编译器变得越来越聪明（或者有人会说越来越狡猾），问题的界限不断变化。

因此，实际上，如果您想编写保证能够正常工作并且可以长时间工作的代码，则只有一种选择：不惜一切代价避免出现不确定的行为。确实，如果您涉足其中，它将再次困扰您。

您的示例不考虑的一件事就是优化。 a是在循环中设置的，但从未使用过，优化器可以解决该问题。因此，优化器a完全丢弃是合理的，在这种情况下，所有未定义的行为都将像布儒姆的受害者一样消失。

但是，这当然是不确定的，因为优化是不确定的。:)

由于此问题是双重标记的C和C ++，因此我将尝试同时解决这两个问题。C和C ++在这里采用不同的方法。

在C语言中，实现必须能够证明将调用未定义的行为，以便将整个程序视为具有未定义的行为。在OP的示例中，编译器证明这一点似乎微不足道，因此就好像整个程序都未定义一样。

我们可以从缺陷报告109中看到这一点，它的症结在于：

但是，如果C标准认识到“未定义的值”的单独存在（其创建不完全涉及“未定义的行为”），那么进行编译器测试的人员可以编写如下的测试用例，并且他/她也可以期望（或可能要求）合格的实现至少应编译该代码（并可能还允许其执行）而不会出现“失败”。

int array1[5];
int array2[5];
int *p1 = &array1[0];
int *p2 = &array2[0];

int foo()
{
int i;
i = (p1 > p2); /* Must this be "successfully translated"? */
1/0; /* Must this be "successfully translated"? */
return 0;
}

因此，最重要的问题是：上面的代码是否必须“成功翻译”（意味着什么）？（参见5.1.1.3节的脚注。）

响应是：

C标准使用术语“不确定值”而非“不确定值”。使用不确定值的对象会导致不确定的行为。条款5.1.1.3的脚注指出，只要有效的程序仍能正确翻译，实现就可以自由生成任何数量的诊断信息。 如果在需要常量表达式的上下文中出现其撤回将导致未定义行为的表达式，则包含程序并不严格符合。此外，如果给定程序的所有可能执行都会导致未定义的行为，则该给定程序不是严格符合要求的。 合格的实现一定不能仅仅因为某个程序的某些可能执行会导致不确定的行为而翻译严格合格的程序。因为可能永远不会调用foo，所以给定的示例必须通过符合标准的实现成功翻译。

在C ++中，该方法似乎更宽松，并且将建议程序具有未定义的行为，而不管实现是否可以静态证明它。

我们有[intro.abstrac] p5，其中说：

执行格式正确的程序的合格实现应产生与具有相同程序和相同输入的抽象机相应实例的可能执行之一相同的可观察行为。但是，如果任何这样的执行包含未定义的操作，则本文档对使用该输入执行该程序的实现没有任何要求（甚至不涉及第一个未定义的操作之前的操作）。

最佳答案是一个错误（但很常见）的误解：

未定义的行为是运行时属性*。它不能“时间旅行”！

某些操作（根据标准）定义为具有副作用，无法进行优化。执行I / O或访问volatile变量的操作属于此类别。

但是，有一个警告：UB可以是任何行为，包括撤消先前操作的行为。在某些情况下，这可能会对优化早期代码产生类似的结果。

实际上，这与最佳答案中的引用（强调我的）一致：

执行格式正确的程序的合格实现应产生与具有相同程序和相同输入的抽象机相应实例的可能执行之一相同的可观察行为。
但是，如果任何这样的执行包含未定义的操作，则此国际标准对使用该输入执行该程序的实现没有任何要求（甚至不涉及第一个未定义的操作之前的操作）。

是的，此引号确实说“甚至不涉及第一个未定义操作之前的操作”，但请注意，这特别是与正在执行的代码有关，而不仅仅是编译。
毕竟，实际上未达到的未定义行为不会做任何事情，并且要实际到达包含UB的行，必须先执行它之前的代码！

因此，是的，一旦执行了UB，先前操作的任何效果都将变得不确定。但是在此之前，程序的执行是明确定义的。

但是请注意，可以将导致这种情况的程序的所有执行优化为等效程序，包括执行先前操作但撤消其效果的程序。因此，只要这样做，前面的代码就可能被优化掉，这等同于取消它们的效果。否则，不能。参见以下示例。

*注：这是不是不一致UB发生在编译时。如果编译器确实可以证明将始终对所有输入执行UB代码，则UB可以延长编译时间。但是，这需要知道所有先前的代码最终都会返回，这是一个很强的要求。同样，请参见下面的示例/说明。

要具体说明，请注意以下代码必须打印foo并等待您的输入，而不管其后发生的任何未定义行为：

printf("foo");
getchar();
*(char*)1 = 1;

但是，还请注意，不能保证foo在UB发生后仍会保留在屏幕上，或者不能保证您键入的字符将不再位于输入缓冲区中。这两个操作都可以“撤消”，与UB“时间旅行”具有相似的效果。

如果getchar()行是不存在，这将是合法的线路被优化掉，当且仅当那将是没有区别的输出foo，然后“非做”吧。

两者是否难以区分将完全取决于实现（即，取决于编译器和标准库）。例如，您可以在等待另一个程序读取输出时在这里printf 阻塞线程吗？还是会立即返回？

• 如果它可以在此处阻塞，则另一个程序可以拒绝读取其完整输出，并且它可能永远不会返回，因此UB可能永远不会出现。

• 如果它可以立即返回此处，那么我们知道它必须返回，因此，对其进行优化与执行然后取消其效果完全没有区别。

当然，由于编译器知道其特定版本允许的行为printf，因此可以进行相应的优化，因此printf在某些情况下可能会优化，而在其他情况下则无法优化。但是，再次有理由证明，这与UB取消先前的操作是无法区分的，不是因为UB而使先前的代码“中毒了”。