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標準によれば、符号付き整数オーバーフローは 未定義の動作であるということです。 言い換えると、標準によれば、符号付きオーバーフローが発生するとすぐに、プログラムはnullポインターを逆参照した場合と同じように無効になります。したがって、上記の事後条件チェックの例のように、未定義の動作を引き起こして、事後にオーバーフローを検出しようとすることはできません。

上記のチェックは多くのコンパイラで機能する可能性がありますが、信頼することはできません。実際、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;
}

このような加算を実行してもオーバーフローが発生しないことを事前に確認するまで、実際には2つの整数を加算しないため、これはより有望に思えます。したがって、未定義の動作を引き起こすことはありません。

ただし、このソリューションは、加算操作が機能するかどうかをテストするためだけに減算操作を実行する必要があるため、残念ながら最初のソリューションよりもはるかに効率が低くなります。そして、この（小さな）パフォーマンスの低下を気にしなくても、このソリューションが適切であると完全に確信しているわけではありません。表現lhs <= INT_MIN - rhsは、符号付きオーバーフローは不可能であると考えて、コンパイラーが最適化するようなとまったく同じように見えます。

それで、ここにもっと良い解決策はありますか？1）未定義の動作を引き起こさないこと、および2）オーバーフローチェックを最適化する機会をコンパイラに提供しないことが保証されているものはありますか？両方のオペランドをunsignedにキャストし、独自の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サイズの加算と単一の条件付きジャンプオンオーバーフローに変換する必要があり、実際に大きな加算を実行することはありません。

編集：スティーブンが指摘したように、私は（あまり良くない）コンパイラgccを取得して正常なasmを生成するのに問題があります。それが生成するコードはそれほど遅くはありませんが、確かに最適ではありません。gccに正しいことをさせるこのコードの変種を誰かが知っているなら、私はそれらを見てみたいです。

いいえ、2番目のコードは正しくありませんが、近いです：設定した場合

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には、不等式の両側をシンボリックに追加する必要があります。これにより、結果が範囲外であるという算術条件が正確に得られます。

IMHO、オーバーフローセンシティブC ++コードを処理する最も簡単な方法は、を使用することSafeInt<T>です。これは、コードプレックスでホストされているクロスプラットフォームのC ++テンプレートであり、ここで必要な安全性を保証します。

• http://safeint.codeplex.com/

通常の数値演算と同じ使用パターンの多くを提供し、例外を介してフローの上下を表現するため、非常に直感的に使用できます。

gccの場合、gcc 5.0リリースノートから、__builtin_add_overflowオーバーフローをチェックするためのが追加で提供されることがわかります。

オーバーフローチェックを備えた算術演算用の組み込み関数の新しいセットが追加されました：__ builtin_add_overflow、__ builtin_sub_overflow、および__builtin_mul_overflow、およびclangとの互換性のために他のバリアントもあります。これらのビルトインには2つの整数引数（同じ型である必要はありません）があり、引数は無限精度の符号付き型に拡張され、+、-、または*がそれらに対して実行され、結果はを指す整数変数に格納されます最後の引数で。格納された値が無限精度の結果と等しい場合、組み込み関数はfalseを返し、そうでない場合はtrueを返します。結果を保持する整数変数のタイプは、最初の2つの引数のタイプとは異なる場合があります。

例えば：

__builtin_add_overflow( rhs, lhs, &result )

gccドキュメントから、オーバーフローチェックで算術演算を実行するための組み込み関数を確認できます。できます。

[...]これらの組み込み関数には、すべての引数値に対して完全に定義された動作があります。

clangは、チェックされた算術ビルトインのセットも提供します。

Clangは、Cで高速かつ簡単に表現できる方法で、セキュリティが重要なアプリケーションのチェック演算を実装する一連の組み込み関数を提供します。

この場合、組み込みは次のようになります。

__builtin_sadd_overflow( rhs, lhs, &result )

インラインアセンブラを使用する場合は、オーバーフローフラグを確認できます。もう1つの可能性は、safeintデータ型を使用できることです。整数セキュリティに関するこのペーパーを読むことをお勧めします。

可能な最速の方法は、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ビルトインの使用に問題がある場合、次に速い方法は、符号ビットでビット演算を使用することです。さらに、次の場合に符号付きオーバーフローが発生します。

• 2つのオペランドの符号は同じであり、
• 結果の符号はオペランドとは異なります。

の符号ビットは~(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;  
} 

これにより、未定義の符号付きオーバーフロー動作が、符号付きと符号なしの間の範囲外の値の実装定義の変換に置き換えられるため、コンパイラのドキュメントをチェックして、何が起こるかを正確に知る必要がありますが、少なくとも十分に定義されている必要があります。変換時にシグナルを生成しない2の補数マシンで正しいことを行う必要があります。これは、過去20年間に構築されたほとんどすべてのマシンとCコンパイラです。

2つのlong値を追加する場合、ポータブルコードはlong値を低いint部分と高い部分に分割できます（または、と同じサイズのshort場合longは部分に分割できますint）。

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は、加算と減算の間が変更された可能性ができなくなります。

x86_64にgcc4.4.3を使用すると、このコードのアセンブリは加算、減算、およびテストを実行しますが、スタックおよび不要なスタック操作のすべてを格納します。私も試しましたregister volatile int sum =が、組み立ては同じでした。

int sum =（揮発性またはレジスタがない）バージョンのみの場合、関数はテストを実行せず、1つの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 

未定義の振る舞いにつながりますか？Intelx86命令セットリファレンスにはそのようなものはありません。