整数オーバーフローで移植するのは良い考えではない理由

この記事では、特に符号付き整数オーバーフローのコンテキストにおける未定義の動作とコンパイラーの最適化に焦点を当てています。



翻訳者からの注意：ロシア語では、「ラップ」/「ラッピング」という言葉の使用された文脈には明確な対応がありません。 説明されている現象に近い数学用語「 転送 」があり、用語「キャリーフラグ」は整数オーバーフロー中にプロセッサにフラグを設定するメカニズムです。 別の翻訳オプションは、「回転/反転/ゼロを中心とした回転」というフレーズです。 「キャリー」よりも「ラップ」の意味がよく反映されています。 正の範囲から負の範囲にオーバーフローするときの数値の推移を示します。 しかし、判明したように、これらの単語はテストリーダーのテキストでは珍しく見えます。 簡単にするために、将来的には「転送」という言葉を「ラップ」という用語の翻訳として使用します。



作業中のC言語（およびC ++）のコンパイラーは、 不定の動作の概念によってますます導かれています -一部の操作のプログラムの動作は標準によって規制されておらず、オブジェクトコードを生成するとき、コンパイラーはプログラムがそのような操作を実行しないという仮定から進む権利を持っているという概念 この場合、生成されたコードはプログラムの作成者が意図したとおりに動作しない可能性があるため、多くのプログラマがこのアプローチに反対しました。 コンパイラーがより洗練された最適化手法を使用しているため、この問題はより深刻になっています。これはおそらく不定の動作の概念に基づいているでしょう。



これに関連して、符号付き整数オーバーフローの例が示されています。 ほとんどのC開発者は、 追加のコードを使用して整数を表すマシン用のコードを記述します。この表現での加算と減算は、まったく同じ方法で符号なし算術で実装されます。 符号付きの2つの正の整数の合計がオーバーフローした場合、つまり、型が対応するサイズより大きくなった場合、プロセッサは符号付き数値の2進補数として解釈される値を負と見なします。 この現象は「転送」と呼ばれます。これは、値の範囲の上限に達した結果が「転送」され、下限から始まるためです。



このため、Cで次のコードを見ることができます。

int b = a + 1000; if (b < a) { //  puts("input too large!"); return; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ifステートメントのタスクは、オーバーフロー条件（この場合、変数aの値に1000を追加した後に発生する ）を検出し、エラーを報告することです。 問題は、Cでは、符号付き整数オーバーフローが未定義の動作のケースの1つであることです。 しばらくの間、コンパイラーは常にこのような条件をfalseと見なしてきました。1000（または他の正の数）を別の数に加算すると、結果は初期値より小さくなりません。 オーバーフローが発生すると、不明確な動作が発生します。これを許可しないことは、すでに（明らかに）プログラマー自身の関心事です。 したがって、コンパイラーは、最適化の目的で条件演算子を完全に削除できると判断できます（結局、条件は常にfalseであり、何にも影響しないため、それなしでも実行できます）。



問題は、この最適化により、コンパイラーが未定義の動作を検出して処理するためにプログラマーが追加したチェックを削除したことです。 ここでは、実際にこれがどのように起こるかを見ることができます。 （注：サンプルをホストしているgodbolt.orgサイトは非常にクールです！コードを編集して、さまざまなコンパイラーがどのように処理するかをすぐに確認できます。 Cで符号なしオーバーフローの動作が定義されているため、型を符号なしに変更しても、コンパイラーはオーバーフローのチェックを削除しないことに注意してください（より正確には、結果は符号なし算術で転送されるため、オーバーフローは実際には発生しません）。



これは間違っていますか？ 多くのコンパイラ開発者がこの決定を合法と見なしていることは明らかですが、誰かがイエスと言います。 私が正しく理解している場合、オーバーフロー時の転送のサポーター（編集：実装依存）の主な引数は次のとおりです。

• オーバーフローは便利な動作です。
• 移行は、プログラマが期待する動作です。
• 無期限のオーバーフロー動作のセマンティクスは、顕著な利点を提供しません。
• 未定義の動作に関するC言語標準により、実装は「状況を完全に無視し、結果は予測不能になります」が、これは未定義の動作を伴う状況がまったく発生しないという仮定に基づいて、コンパイラーにコードを最適化する権利を与えません。

各アイテムを順番に分析しましょう。



オーバーフロー移行-有用な動作？



移行は、主に、すでに発生したオーバーフローを追跡する必要がある場合に役立ちます。 （転送によって解決でき、符号なし整数変数を使用して解決できない他の問題がある場合、そのような例をすぐに思い出せず、それらの多くはないと思われます）。 転送は、誤ってオーバーフローした変数を使用する問題を実際に簡素化しますが、万能薬ではありません（未知の符号を持つ2つの未知の量の乗算または加算を忘れないでください）。



些細なケースでは、転送によって、発生したオーバーフローを追跡できる場合、それが発生するかどうかを事前に知ることも難しくありません。 この例は次のように書き換えることができます。

 if (a > INT_MAX - 1000) { //    puts("input too large!"); return; } int b = a + 1000;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、合計を計算してからオーバーフローが発生したかどうかを確認し、数学的な一貫性の結果を確認する代わりに、合計が型に適合する最大数を超えているかどうかを確認できます。 （両方のオペランドの符号が不明な場合、検証は非常に複雑になる必要がありますが、転送中の検証にも同じことが当てはまります）。



このすべてを考えると、ほとんどの場合、転移が有用であるという説得力のない議論を見つけます。



プログラマーが期待する動作は移行ですか？



少なくとも一部の Cプログラマーのコードが符号付き整数オーバーフローを伴う転送セマンティクスを想定していることは明らかであるため、この引数について議論することはより困難です。 しかし、この事実だけでは、このようなセマンティクスを望ましいと考えるには不十分です（必要に応じて、一部のコンパイラーで有効にできることに注意してください）。



問題に対する明らかな解決策（プログラマーはこの動作を期待します）は、未定義の動作がないと仮定して、コードを最適化するときにコンパイラーに警告を出すことです。 残念ながら、上記のリンクを使用したgodbolt.orgの例で見たように、コンパイラは常にこれを行うとは限りません（Gccバージョン7.3-はい、バージョン8.1-いいえ、それで一歩後退します）。



無期限のオーバーフロー動作のセマンティクスには顕著な利点はありませんか？



このコメントがすべての場合に当てはまる場合、コンパイラはデフォルトで転送セマンティクスに従うべきであるという事実を支持する強力な引数として機能します。これは、このメカニズムが技術的な観点から間違っていても、おそらくオーバーフローチェックを許可する方がよいからです破損した可能性のあるコードで使用できるためです。



通常のCプログラムでのこの最適化（数学的に矛盾する条件のチェックの除去）は、作者が最高のパフォーマンスを目指して努力し、コードを手動で最適化するため、無視されることが多いと想定しています：つまり、このifステートメントに条件が含まれていることが明らかな場合 、これは決して真実ではありませんが、プログラマーは自分で削除する可能性があります。 実際、いくつかの研究で、このような最適化の有効性が疑問視され、テストされ、制御テストのフレームワークでは実質的に重要でないことがわかりました。 ただし、この最適化はCではほとんど利点を提供しませんが、コードジェネレーターとコンパイラーの最適化はほとんどの部分で普遍的であり、他の言語でも使用できます。 C ++言語を使用してみましょう。たとえば、手動で行うのではなく、オプティマイザーに依存してテンプレートコード内の冗長な構造を削除するという伝統があります。 しかし、トランスポーターによってCに変換される言語があり、それらの冗長コードもCコンパイラーによって最適化されます。



さらに、オーバーフローをチェックし続けても、追加のコードを使用するマシンであっても、整数変数を転送する直接的なコストが最小限になるということはまったくありません。 たとえば、Mipsアーキテクチャは、固定サイズ（32ビット）のレジスタでのみ算術演算を実行できます。 通常 、 short int型のサイズは16ビットで、 char -8ビットです。 これらのタイプのいずれかの変数がレジスターに格納されると、そのサイズが拡大し、それを正しく転送するために、少なくとも1つの追加操作を実行し、場合によっては追加のレジスターを使用する必要があります（対応するビットマスクに対応するため）。 長い間Mipsコードを扱っていないことを認めざるを得ないので、これらの操作の正確なコストについてはわかりませんが、ゼロ以外であり、他のRISCアーキテクチャでも同じ問題が発生する可能性があると確信しています。



言語規格は、アーキテクチャで意図されている場合、変数転送の回避を禁止していますか？



見ると、この議論は特に弱いです。 その本質は、標準によって、実装（コンパイラ）が限られた範囲でのみ「不定の動作」を解釈できるようにすることです。 規格自体のテキストで-移転の支持者が訴えるその断片で-次のように言われています（これは「不定行動」という用語の定義の一部です）：



注： 未定義の動作は、状況を完全に無視するという形をとる場合がありますが、結果は予測不可能です...



「状況を完全に無視する」という言葉は、未定義の動作（たとえば、追加中のオーバーフロー）につながるイベントが発生しないことを示唆しているのではなく、もしそうであれば、コンパイラは発生したことはありませんが、プロセッサにそのような操作を実行する要求を送信した場合に発生する結果も考慮します（つまり、ソースコードが単純で素朴な方法でマシンコードに変換されたかのように）。



まず、このテキストは「メモ」として与えられているため、標準の概要で言及されているISO指令に従って、規範的ではない（つまり、何かを規定できない）ことに注意する必要があります。



ISO / IEC指令のパート3に従って、この序文、本文の紹介、メモ、脚注、および例も情報提供のみを目的としています。



この「不定の動作」の一節はメモであるため、何も規定していません。 「不定の動作」の現在の定義は次のとおりです。



許容できない、または不正確なソフトウェア設計または不正確なデータの使用に起因する振る舞い。 この国際規格では要件を課していません 。



私は主なアイデアを強調しました：不明確な振る舞いに要件は課されません。 注の「可能なタイプの未定義の動作」のリストには、例のみが含まれており、最終的な処方箋にすることはできません。 それ以外の場合、「要求を行わない」というフレーズは解釈できません。



この議論を展開して、テキストに関係なく、言語委員会はこれらの単語を定式化したとき、全体としての動作はプログラムが実行されているハードウェアのアーキテクチャに可能な限り対応する必要があると主張し、素朴な翻訳を暗示していますマシンコードに。 これは真実かもしれませんが、この議論を支持する証拠（例えば、歴史的文書）を見たことはありません。 ただし、たとえそうであったとしても、この声明がテキストの現在のバージョンに適用されるという事実ではありません。



最後の考え



移転を支持する議論は、大部分が受け入れられない。 おそらく、それらを組み合わせると、最も強力な議論が得られます：経験の少ないプログラマー（C言語の複雑さとその不定の動作を知らない）は、転送を期待することがあり、パフォーマンスを低下させません-後者はすべての場合に当てはまりませんが、最初の部分は決定的ではありません個別に検討する場合。



個人的には、オーバーフローよりもオーバーフローをブロック（トラッピング）するほうが好ましいと思います。 つまり、プログラムがクラッシュし、動作を継続しません-どちらの場合も脆弱性が現れるため、不確実な動作または潜在的に誤った結果が発生します。 もちろん、そのようなソリューションは、ほとんどの（？）アーキテクチャ、特にx86でパフォーマンスをわずかに低下させますが、一方で、オーバーフローエラーはすぐに特定され、それらをさらに使用して、間違った結果を取得することはできませんプログラム。 さらに、理論的には、このアプローチを使用するコンパイラーは冗長なオーバーフローチェックを安全に削除できます。これは確かに発生しないためです。ただし、ClangもGCCもこの機会を使用しません。



幸いなことに、割り込みと移植の両方が、私が最も頻繁に使用するコンパイラーであるGCCに実装されています。 モードを切り替えるには、それぞれ-ftrapvおよび-fwrapvコマンドライン引数が使用されます。



もちろん、未定義の動作につながる多くのアクションがあります-整数オーバーフローはそれらの1つにすぎません。 これらのすべてのケースを未定義の動作として解釈することは有用であるとはまったく思いません。また、言語によってセマンティクスが決定されるか、少なくとも実装の裁量に委ねられる特定の状況が多くあると確信しています。 コンパイラメーカーによるこの概念の過度に自由な解釈が怖いのです。コンパイラの動作が開発者、特に個人的に標準のテキストを読んでいる開発者の直感的なアイデアに合わない場合、これは本当のエラーにつながる可能性があります。 この場合の生産性の向上が無視できる場合、そのような解釈を放棄する方がよいでしょう。 以下の投稿のいずれかで、これらの問題のいくつかを検討します。



サプリメント（2018年8月24日付け）



上記の多くがより良く書けることに気づきました。 以下に、私の言葉を簡単に要約して説明し、いくつかの小さなコメントを追加します。

• 私は、不明確な振る舞いがオーバーフローを運ぶために好ましいと主張しませんでした-むしろ、 実際には、転送は不定の振る舞いよりもはるかに優れていません 。 特に、最初の場合と2番目の場合にセキュリティの問題が発生する可能性があります-そして、時間内に捕捉されなかったオーバーフローによって引き起こされる脆弱性の多くは（コンパイラが誤ったチェックを削除する責任があるものを除く） -結果の転送が原因ですが、オーバーフローに関連する未定義の動作が原因ではありません。
• 転送の唯一の本当の利点は、オーバーフローチェックが削除されないことです。 この方法でいくつかの攻撃シナリオからコードを保護できますが、オーバーフローの一部はまったくチェックされない（つまり、プログラマーがそのようなチェックを追加するのを忘れる）ことに気付かれない可能性があります。
• セキュリティの問題がそれほど重要ではなく、プログラムの高速化が前面に出た場合、未定義の動作は、少なくともいくつかの場合で、より有利な最適化と生産性の大幅な向上をもたらします。 一方、セキュリティが最初に来る場合、移植には脆弱性が伴います。
• つまり、中断、転送、未定義の動作のいずれかを選択した場合、転送が役立つタスクはほとんどありません。
• 発生したオーバーフローのチェックについては、それらを残すことは有害であると信じています。 オーバーフローを中断すると、この問題を回避できます。 適切な警告-軽減してください。
• セキュリティクリティカルなコードを記述する開発者は、その落とし穴に注意するだけでなく、記述する言語のセマンティクスを十分に理解していることが理想的です。 Cの場合、これは、オーバーフローのセマンティクスと未定義の動作の微妙さを知る必要があることを意味します。 一部のプログラマーがこのレベルまで成長していないのは悲しいことです。
• 「ほとんどのCプログラマーはデフォルトの動作として移行を期待している」という主張に出くわしましたが、その証拠はわかりません。 （この記事では、実際の生活からいくつかの例を知っているため、「一部のプログラマー」を作成しました。一般的に、誰かがこれに反論することはないでしょう。）
• 2つの異なる問題があります。C言語標準が要求するものと、コンパイラーが実装すべきものです。 私は（一般に）標準が未定義のオーバーフロー動作を定義する方法が好きです。 この投稿では、コンパイラーがすべきことについて話しています。
• オーバーフローが中断された場合、すべての操作をチェックする必要はありません。 理想的には、このアプローチを使用したプログラムは、数学的な規則に関して一貫して動作するか、動作を停止します。 この場合、「一時的なオーバーフロー」の存在が可能になり、誤った結果が表示されることはありません。 次に、式a + b-bと式（a * b）/ bの両方をaに最適化できます（前者も転送中に可能ですが、後者はもはや存在しません）。

ご注意 記事の翻訳は、著者の許可を得てブログに公開されています。 元のテキスト：Davin McCall「 整数オーバーフローでラップすることはお勧めできません 」。



PVS-Studioチームからの追加の関連リンク：

1. アンドレイ・カルポフ。 未定義の振る舞いは、あなたが考えるよりも近いです 。
2. Will Dietz、Peng Li、John Regehr、Vikram Adve。 C / C ++の整数オーバーフローを理解する 。
3. V1026。 変数はループ内でインクリメントされます。 符号付き整数オーバーフローの場合、未定義の動作が発生します。
4. Stackoverflow C ++では符号付き整数オーバーフローは未定義の動作ですか？