在C / C ++中检测签名溢出

乍一看，这个问题似乎与“如何检测整数溢出”重复出现。，但实际上有很大的不同。

我发现，虽然检测无符号整数溢出非常简单，但是在C / C ++中检测带符号溢出实际上比大多数人想象的要困难。

最明显但最幼稚的方式是：

int add(int lhs, int rhs)
{
 int sum = lhs + rhs;
 if ((lhs >= 0 && sum < rhs) || (lhs < 0 && sum > rhs)) {
  /* an overflow has occurred */
  abort();
 }
 return sum; 
}

这样做的问题是根据C标准，有符号整数溢出是未定义的行为。 换句话说，根据标准，甚至在导致签名溢出时，程序就如同取消引用空指针一样无效。因此，您不能导致未定义的行为，然后尝试在事后检测溢出，如上述后置条件检查示例中所示。

即使上面的检查可能在许多编译器上都有效，但您不能指望它。实际上，由于C标准说未定义有符号整数溢出，因此某些编译器（如GCC）会在设置优化标志时优化上述检查，因为编译器认为有符号溢出是不可能的。这完全中断了检查溢出的尝试。

因此，另一种检查溢出的可能方法是：

int add(int lhs, int rhs)
{
 if (lhs >= 0 && rhs >= 0) {
  if (INT_MAX - lhs <= rhs) {
   /* overflow has occurred */
   abort();
  }
 }
 else if (lhs < 0 && rhs < 0) {
  if (lhs <= INT_MIN - rhs) {
   /* overflow has occurred */
   abort();
  }
 }

 return lhs + rhs;
}

这似乎更有希望，因为在事先确保执行此类加法操作不会导致溢出之前，我们实际上不会将两个整数相加。因此，我们不会引起任何未定义的行为。

但是，不幸的是，该解决方案的效率比初始解决方案低很多，因为您必须执行减法运算只是为了测试加法运算是否有效。即使您不关心这种（小的）性能下降，我仍然不完全相信此解决方案是足够的。该表达式lhs <= INT_MIN - rhs似乎完全类似于编译器可能会优化掉的那种表达式，认为有符号溢出是不可能的。

那么，这里有更好的解决方案吗？是否可以保证1）不会导致未定义的行为，以及2）不能为编译器提供优化溢出检查的机会？我当时想通过将两个操作数都转换为无符号，然后通过滚动自己的二进制补码算术执行检查可能有某种方法，但是我不确定如何做到这一点。

您的减法方法是正确且定义明确的。编译器无法对其进行优化。

如果您有较大的整数类型可用，另一种正确的方法是在较大的类型上执行算术，然后在将其转换回时检查结果是否适合较小的类型

int sum(int a, int b)
{
    long long c;
    assert(LLONG_MAX>INT_MAX);
    c = (long long)a + b;
    if (c < INT_MIN || c > INT_MAX) abort();
    return c;
}

一个好的编译器应该将整个加法和if语句转换为一个int-size的加法和一个有条件的溢出跳转，并且切勿实际执行较大的加法。

编辑：正如斯蒂芬指出的那样，我在获取一个（不太好的）编译器gcc来生成合理的asm时遇到了麻烦。它生成的代码并不是很慢，但是肯定不是最优的。如果有人知道此代码的变体，这些变体将使gcc做正确的事情，我很乐意看到它们。

不，您的第二个密码不正确，但是您很接近：如果您设置

int half = INT_MAX/2;
int half1 = half + 1;

相加的结果是INT_MAX。（INT_MAX始终为奇数）。因此，这是有效的输入。但是，在您的例行工作中，您将拥有INT_MAX - half == half1并会中止。误报。

可以通过放入<而不是<=同时放入两个检查来修复此错误。

但是，您的代码也不是最优的。将执行以下操作：

int add(int lhs, int rhs)
{
 if (lhs >= 0) {
  if (INT_MAX - lhs < rhs) {
   /* would overflow */
   abort();
  }
 }
 else {
  if (rhs < INT_MIN - lhs) {
   /* would overflow */
   abort();
  }
 }
 return lhs + rhs;
}

为了证明这是有效的，您必须lhs在不等式的两边进行符号加法，这为您提供了精确的算术条件，即结果超出范围。

恕我直言，处理溢出的敏感C ++代码最简便的方法是使用SafeInt<T>。这是托管在代码plex上的跨平台C ++模板，可在此处提供您所需的安全性保证。

• http://safeint.codeplex.com/

我发现它使用起来非常直观，因为它提供了许多与普通数值运算相同的使用模式，并通过异常表示了上下流动。

对于gcc情况，从gcc 5.0发行说明中我们可以看到，它现在还提供了一个__builtin_add_overflow检查溢出的方法：

添加了一组新的用于带有溢出检查的算术的内置函数：__builtin_add_overflow，__builtin_sub_overflow和__builtin_mul_overflow，以及与clang的兼容性以及其他变体。这些内建函数具有两个整数参数（不必具有相同的类型），这些参数扩展为无限精度带符号类型，对它们执行+，-或*，并将结果存储在指向的整数变量中最后一个论点。如果存储的值等于无限精度结果，则内置函数返回false，否则返回true。用于保存结果的整数变量的类型可以与前两个参数的类型不同。

例如：

__builtin_add_overflow( rhs, lhs, &result )

我们可以从gcc文档中看到使用溢出执行算术的内置函数。

这些内置函数对所有参数值具有完全定义的行为。

clang还提供了一组经过检查的算术内置函数：

Clang提供了一组内置程序，这些内置程序以安全快捷的方式在C语言中实现对安全性至关重要的应用程序执行检查算法。

在这种情况下，内置将是：

__builtin_sadd_overflow( rhs, lhs, &result )

如果使用内联汇编器，则可以检查溢出标志。另一种可能性是可以使用safeint数据类型。我建议阅读有关Integer Security的本文。

最快的方法是使用内置的GCC：

int add(int lhs, int rhs) {
    int sum;
    if (__builtin_add_overflow(lhs, rhs, &sum))
        abort();
    return sum;
}

在x86上，GCC将其编译为：

    mov %edi, %eax
    add %esi, %eax
    jo call_abort 
    ret
call_abort:
    call abort

它使用处理器的内置溢出检测。

如果您对使用GCC内置函数不满意，那么下一个最快的方法是对符号位使用位操作。此外，在以下情况下还会发生签名溢出：

• 这两个操作数具有相同的符号，并且
• 结果的符号与操作数的符号不同。

的符号位~(lhs ^ rhs)是当且仅当操作数具有相同的符号，而符号位lhs ^ sum是当且仅当结果比操作数不同的符号。因此，您可以以无符号形式进行加法操作以避免未定义的行为，然后使用符号位~(lhs ^ rhs) & (lhs ^ sum)：

int add(int lhs, int rhs) {
    unsigned sum = (unsigned) lhs + (unsigned) rhs;
    if ((~(lhs ^ rhs) & (lhs ^ sum)) & 0x80000000)
        abort();
    return (int) sum;
}

编译成：

    lea (%rsi,%rdi), %eax
    xor %edi, %esi
    not %esi
    xor %eax, %edi
    test %edi, %esi
    js call_abort
    ret
call_abort:
    call abort

这比在32位计算机（使用gcc）上转换为64位类型要快得多：

    push %ebx
    mov 12(%esp), %ecx
    mov 8(%esp), %eax
    mov %ecx, %ebx
    sar $31, %ebx
    clt
    add %ecx, %eax
    adc %ebx, %edx
    mov %eax, %ecx
    add $-2147483648, %ecx
    mov %edx, %ebx
    adc $0, %ebx
    cmp $0, %ebx
    ja call_abort
    pop %ebx
    ret
call_abort:
    call abort

您可能会比较幸运，可以转换为64位整数并测试类似的条件。例如：

#include <stdint.h>

...

int64_t sum = (int64_t)lhs + (int64_t)rhs;
if (sum < INT_MIN || sum > INT_MAX) {
    // Overflow occurred!
}
else {
    return sum;
}

您可能想仔细看看符号扩展在这里如何工作，但我认为这是正确的。

怎么样：

int sum(int n1, int n2)
{
  int result;
  if (n1 >= 0)
  {
    result = (n1 - INT_MAX)+n2; /* Can't overflow */
    if (result > 0) return INT_MAX; else return (result + INT_MAX);
  }
  else
  {
    result = (n1 - INT_MIN)+n2; /* Can't overflow */
    if (0 > result) return INT_MIN; else return (result + INT_MIN);
  }
}

我认为，应该为任何合法的工作INT_MIN和INT_MAX（对称或不）; 该功能如图所示，但如何获得其他行为应该很明显）。

显而易见的解决方案是将其转换为unsigned，以获得定义明确的unsigned溢出行为：

int add(int lhs, int rhs) 
{ 
   int sum = (unsigned)lhs + (unsigned)rhs; 
   if ((lhs >= 0 && sum < rhs) || (lhs < 0 && sum > rhs)) { 
      /* an overflow has occurred */ 
      abort(); 
   } 
   return sum;  
} 

这用未定义的有符号和无符号之间的范围外的值的实现定义的转换来替换未定义的有符号溢出行为，因此您需要检查编译器的文档以确切了解将要发生的情况，但是至少应该对其进行良好定义，并且应该在任何不会产生转换信号的二进制补码机器上做正确的事情，这几乎是过去20年中构建的每台机器和C编译器。

如果将两个long值相加，则可移植代码可以将long值分为上下两个int部分（或大小与相同的short部分）：longint

static_assert(sizeof(long) == 2*sizeof(int), "");
long a, b;
int ai[2] = {int(a), int(a >> (8*sizeof(int)))};
int bi[2] = {int(b), int(b >> (8*sizeof(int))});
... use the 'long' type to add the elements of 'ai' and 'bi'

如果针对特定CPU，则使用内联汇编是最快的方法：

long a, b;
bool overflow;
#ifdef __amd64__
    asm (
        "addq %2, %0; seto %1"
        : "+r" (a), "=ro" (overflow)
        : "ro" (b)
    );
#else
    #error "unsupported CPU"
#endif
if(overflow) ...
// The result is stored in variable 'a'

我认为这可行：

int add(int lhs, int rhs) {
   volatile int sum = lhs + rhs;
   if (lhs != (sum - rhs) ) {
       /* overflow */
       //errno = ERANGE;
       abort();
   }
   return sum;
}

使用volatile会使编译器无法优化测试，因为它认为sum加法和减法之间可能有所变化。

使用gcc 4.4.3 for x86_64，此代码的程序集确实进行了加法，减法和测试，尽管它将所有内容存储在堆栈中以及不需要的堆栈操作。我什至试过了，register volatile int sum =但程序集是一样的。

对于仅具有int sum =（没有易失性或寄存器）版本的功能，该功能不进行测试，仅使用一条lea指令（lea即负载有效地址，通常用于在不触摸标志寄存器的情况下进行加法）进行加法。

您的版本是较大的代码，并且有很多跳转，但是我不知道哪个更好。

对我来说，最简单的检查就是检查操作数的符号和结果。

让我们检查一下总和：仅当两个操作数具有相同的符号时，溢出才可能在+或-两个方向上发生。而且，很明显，当结果的符号与操作数的符号不同时，就会发生溢出。

因此，这样的检查就足够了：

int a, b, sum;
sum = a + b;
if  (((a ^ ~b) & (a ^ sum)) & 0x80000000)
    detect_oveflow();

编辑：如尼尔斯建议的，这是正确的if条件：

((((unsigned int)a ^ ~(unsigned int)b) & ((unsigned int)a ^ (unsigned int)sum)) & 0x80000000)

而自从当指令

add eax, ebx 

导致不确定的行为？英特尔x86指令集引用中没有这样的东西。