Visual C是否认为有符号整数溢出未定义？

Question

最近，有符号整数溢出在C和C中没有正式定义，这引起了很多关注。然而，给定的实现可能会选择定义它；在C语言中，实现可以设置std:：numeric_limits

Visual C设置< code>std::numeric_limits

我发现一个实例，其中优化程序发出 x86-64 程序集代码，如果将恰好INT_MAX的值传递给特定函数，则该代码的行为不正确。我无法判断这是否是一个错误，因为 Visual C 似乎没有说明是否有符号整数溢出被视为已定义。所以我想知道，它应该在视觉C中定义吗？

编辑:我在阅读Visual C 2013 Update 2中一个讨厌的bug时发现了这个bug，这个bug在Update 1中没有，如果启用了优化，下面的循环会生成错误的机器代码:

void func (int *b, int n)
{
  for (int i = 0; i < n; i++)
    b[i * (n + 1)] = 1;
}

Update 2错误导致重复行的代码生成，就好像它是b[i]=1；，这显然是错误的。它变成了rep stosd。

真正有趣的是，在之前的版本Update 1中有一个奇怪的地方。它生成的代码没有正确处理n完全等于INT_MAX的情况。具体来说，如果n是INT_MAX，乘法将表现为n是long long而不是int-换句话说，添加n 1不会导致结果变成INT_MIN。

这是更新1中的程序集代码：

    movsxd  rax, edx          ; RDX = 0x000000007FFFFFFF; RAX = 0x000000007FFFFFFF.
    test    edx, edx
    jle     short locret_76   ; Branch not taken, because EDX is nonnegative.
    lea     rdx, ds:4[rax*4]  ; RDX = RAX * 4 + 4; RDX becomes 0x0000000200000000.
    nop                       ; But it's wrong. RDX should now be 0xFFFFFFFE00000000.
loc_68:
    mov     dword ptr [rcx], 1
    add     rcx, rdx
    dec     rax
    jnz     short loc_68
locret_76:
    retn

问题是我不知道这是否是编译器错误-在GCC和Clang中，这不是编译器错误，因为这些编译器认为有符号整数溢出/下溢是未定义的。这是否是Visual C中的错误取决于Visual C是否认为有符号整数上溢/下溢未定义。

除此之外，我所看到的所有其他案例都表明，Visual C考虑定义签名溢出/下溢，因此这是一个谜。




Answer 1

对于< code>n == INT_MAX，您的示例可能确实有未定义的行为，但不仅仅是因为有符号整数溢出未定义(Microsoft编译器上可能没有)。相反，您可能正在调用未定义的越界指针算法。

Answer 2

匿名用户

从2016年（VS2015更新3）中发现了一个有趣的花絮：

他们谈到了他们希望在VS2015中引入的新SSA优化器:

C 团队博客 - 介绍新的高级可视化 C 代码优化器

... ... ...

从历史上看，Visual C 没有利用 C 和 C 标准认为溢出的有符号操作未定义的结果这一事实。其他编译器在这方面非常激进，这促使他们决定实现一些利用未定义的整数溢出行为的模式。我们实现了我们认为安全的代码，并且没有在生成的代码中施加任何不必要的安全风险。

所以你有它。我把它读为：“我们从来没有在任何额外的位中编程来利用这个UB”，但是从VS2015/Update3开始，我们会有一些。

我应该注意到，即使在那之前，我也会非常小心，因为对于64位代码和32位变量，如果编译器/优化器简单地将32位有符号整数放入64位寄存器中，无论如何你都会有未定义的。（如“如何不编码：未定义的行为比你想象的更接近”中所示——不幸的是，从博客文章中不清楚他是使用VS2015前还是更新后3。）

因此，我对这整个事件的看法是，MSVC一直认为它是UB，即使过去的优化版本没有特别利用这一事实。新的SAA优化器似乎可以做到这一点。(测试< code >–D2 undefintoverflow –开关是否正常工作将会很有趣。)