ループのどの時点で整数オーバーフローは未定義の動作になりますか？

これは、ここに投稿できないはるかに複雑なコードを含む私の質問を説明するための例です。

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

このプログラムにはa、3番目のループでオーバーフローするため、プラットフォームでの未定義の動作が含まれています。

それにより、プログラム全体の動作が未定義になりますか、それともオーバーフローが実際に発生したですか？コンパイラは、潜在的にそれが出て仕事ができるa だろう、それは未定義ループ全体を宣言し、彼らはすべてのオーバーフローが起こる前にもかかわらず、printfを実行する気にすることはできませんので、オーバーフロー？

_{（CとC ++のタグは異なりますが、両方の言語が異なる場合は回答に興味があるためです。）}

純粋に理論的な答えに興味がある場合、C ++標準では、未定義の動作を「タイムトラベル」することができます。

[intro.execution]/5: 整形式のプログラムを実行する適合実装は、同じプログラムと同じ入力を持つ抽象マシンの対応するインスタンスの可能な実行の1つと同じ観察可能な動作を生成するものとします。ただし、そのような実行に未定義の操作が含まれている場合、この国際規格は、その入力を使用してそのプログラムを実行する実装に要件を課しません（最初の未定義の操作に先行する操作に関しても）

そのため、プログラムに未定義の動作が含まれている場合、プログラム全体の動作は未定義です。

まず、この質問のタイトルを修正しましょう。

未定義の振る舞いは（具体的には）実行の領域ではありません。

未定義の動作は、コンパイル、リンク、ロード、実行のすべてのステップに影響します。

これを固めるためのいくつかの例は、網羅的なセクションがないことを覚えておいてください。

• コンパイラーは、未定義の振る舞いを含むコードの部分は決して実行されないと想定できるため、それらにつながる実行パスはデッドコードであると想定できます。すべてのCプログラマーが、ChrisLattnerによる未定義の動作について知っておくべきことを参照してください。
• リンカは、弱い記号（名前で認識される）の複数の定義が存在する場合、単一定義規則のおかげですべての定義が同一であると想定できます。
• ローダー（ダイナミックライブラリを使用する場合）は同じものを想定できるため、最初に見つかったシンボルを選択します。これは通常LD_PRELOAD、Unixでトリックを使用して通話を傍受するために（ab）使用されます
• ダングリングポインタを使用すると、実行が失敗する可能性があります（SIGSEV）

これが未定義の振る舞いについてとても怖いことです。どのような正確な振る舞いが発生するかを事前に予測することはほぼ不可能です。この予測は、ツールチェーン、基盤となるOSなどの更新のたびに再検討する必要があります...

Michael Spencer（LLVM開発者）によるこのビデオを見ることをお勧めします：CppCon 2016：My Little Optimizer：Undefined Behavior isMagic。

16ビットintを対象とする積極的に最適化されたCまたはC ++コンパイラは、型に追加する際の動作が未定義であることを認識します。1000000000int

それは望んで何もやって、標準で許可されている可能性が残さ、プログラム全体の削除が含まれるがint main(){}。

しかし、より大きなintsはどうですか？私は（と私は任意の手段によって、CおよびC ++コンパイラの設計の専門家ではないよ）まだこれを行い、コンパイラのか分からないが、私はと想像いつか32ビットのターゲットコンパイラint以上がループすることを把握します無限である（i変更しない）と、そうaは最終的にオーバーフロー。したがって、もう一度、出力をに最適化できますint main(){}。ここで私が言いたいのは、コンパイラの最適化が次第に積極的になるにつれて、ますます多くの未定義の動作構造が予期しない方法で現れているということです。

ループ本体の標準出力に書き込んでいるため、ループが無限であるという事実自体は未定義ではありません。

技術的には、C ++標準では、プログラムに未定義の動作が含まれている場合、コンパイル時でもプログラム全体の動作です。（プログラムが実行される前）であっても、プログラムは未定義です。

実際には、コンパイラーは（最適化の一部として）オーバーフローが発生しないと想定する可能性があるため、少なくともループの3回目の反復（32ビットマシンを想定）でのプログラムの動作は未定義になりますが、 3回目の反復の前に正しい結果が得られる可能性があります。ただし、プログラム全体の動作は技術的に未定義であるため、プログラムが完全に誤った出力（出力なしを含む）を生成したり、実行中の任意の時点でクラッシュしたり、コンパイルに失敗したりすることを妨げるものは何もありません（未定義の動作はコンパイル時）。

未定義の振る舞いは、コードが何をしなければならないかについての特定の仮定を排除するため、コンパイラーに最適化する余地を提供します。そうすることで、未定義の動作を含む仮定に依存するプログラムは、期待どおりに動作することが保証されません。そのため、C ++標準で未定義と見なされる特定の動作に依存しないでください。

@TartanLlamaが適切に表現しているように、未定義の動作が「タイムトラベル」できる理由を理解するために、「as-if」ルールを見てみましょう。

1.9プログラムの実行

¹この国際規格のセマンティック記述は、パラメータ化された非決定論的抽象マシンを定義します。この国際規格は、適合実装の構造に要件を課していません。特に、抽象マシンの構造をコピーしたりエミュレートしたりする必要はありません。むしろ、以下で説明するように、抽象マシンの観察可能な動作を（のみ）エミュレートするには、準拠する実装が必要です。

これにより、プログラムを入力と出力を備えた「ブラックボックス」と見なすことができます。入力は、ユーザー入力、ファイル、および他の多くのものである可能性があります。出力は、標準で言及されている「観察可能な動作」です。

この規格は、入力と出力の間のマッピングのみを定義し、他には何も定義していません。これは「ブラックボックスの例」を説明することによって行われますが、同じマッピングを持つ他のブラックボックスも同様に有効であると明示的に述べています。これは、ブラックボックスの内容が無関係であることを意味します。

このことを念頭に置いて、未定義の動作が特定の瞬間に発生すると言っても意味がありません。ブラックボックスのサンプル実装では、いつどこで発生するかを言うことができますが、実際にはブラックボックスはまったく異なるものである可能性があるため、どこでいつ発生するかはわかりません。理論的には、コンパイラーは、たとえば、考えられるすべての入力を列挙し、結果の出力を事前に計算することを決定できます。その場合、コンパイル中に未定義の動作が発生します。

未定義の動作は、入力と出力の間にマッピングが存在しないことです。プログラムは、一部の入力に対して未定義の動作を持つことができますが、他の入力に対しては定義された動作を持つことができます。その場合、入力と出力の間のマッピングは単純に不完全です。出力へのマッピングが存在しない入力があります。
問題のプログラムは、どの入力に対しても未定義の動作をしているため、マッピングは空です。

int32ビットであると仮定すると、未定義の動作は3回目の反復で発生します。したがって、たとえば、ループが条件付きでのみ到達可能である場合、または3番目の反復の前に条件付きで終了できる場合、3番目の反復に実際に到達しない限り、未定義の動作はありません。ただし、未定義の動作が発生した場合、プログラムのすべての出力は未定義になります。これには、未定義の動作の呼び出しに関連する「過去」の出力も含まれます。たとえば、あなたの場合、これは、出力に3つの「Hello」メッセージが表示される保証がないことを意味します。

TartanLlamaの答えは正しいです。未定義の動作は、コンパイル時であってもいつでも発生する可能性があります。これはばかげているように見えるかもしれませんが、コンパイラーが必要なことを実行できるようにするための重要な機能です。コンパイラになるのは必ずしも簡単ではありません。毎回、仕様の内容を正確に実行する必要があります。ただし、特定の動作が発生していることを証明するのが非常に難しい場合があります。停止性問題を覚えているなら、特定の入力が与えられたときにそれが完了するか無限ループに入るかを証明できないソフトウェアを開発するのはかなり簡単です。

コンパイラを悲観的にし、次の命令が問題のようなこれらの停止問題の1つになるのではないかと恐れて絶えずコンパイルすることもできますが、それは合理的ではありません。代わりに、コンパイラにパスを与えます。これらの「未定義の振る舞い」のトピックについては、責任を負いません。未定義の振る舞いは、非常に微妙に悪意のあるすべての振る舞いで構成されているため、本当に厄介で悪意のある停止問題などからそれらを分離するのに問題があります。

ソースを失ったことは認めますが、投稿するのが大好きな例があります。言い換える必要があります。これは、MySQLの特定のバージョンからのものでした。MySQLでは、ユーザー提供のデータで満たされた循環バッファーがありました。もちろん、彼らはデータがバッファをオーバーフローしないことを確認したかったので、彼らはチェックをしました：

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

それは十分に正気に見えます。ただし、numberOfNewCharsが本当に大きく、オーバーフローした場合はどうなりますか？次に、ラップアラウンドして、よりも小さいポインタになるendOfBufferPtrため、オーバーフローロジックが呼び出されることはありません。そこで彼らは、その前に2番目のチェックを追加しました。

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になります。また、スケールがメモリから複数回読み取られると、エンドレスループになる可能性があります。予期せず値を変更しました（「スケール」がUBを呼び出さずにループの途中で変更される可能性がある場合、コンパイラーは最適化を実行できません）。

このような最適化のほとんどは、2つの短い符号なし型を乗算してINT_MAX + 1とUINT_MAXの間にある値を生成する場合には問題ありませんが、gccには、ループ内でこのような乗算を行うとループが早期終了する場合があります。 。生成されたコードの比較命令に起因するこのような動作には気づいていませんが、コンパイラーがオーバーフローを使用して、ループが最大4回以下で実行できると推測する場合に観察できます。推論によってループの上限が無視されたとしても、一部の入力でUBが発生し、他の入力では発生しない場合、デフォルトでは警告は生成されません。

未定義の動作は、定義上、灰色の領域です。何をするか、何をしないかを予測することはできません。それが「未定義の振る舞い」の意味です。です。

太古の昔から、プログラマーは常に未定義の状況から定義の残骸を救おうとしました。彼らはいくつかのコード、彼らが主張しようとするので、彼らは本当に、使用したいが、未定義であることが判明しているんだ：「私はそれが未定義だけど、確かにそれは、最悪で、このまたはこれを行いますが、それは決してしないだろうということを。」そして、時にはこれらの議論は多かれ少なかれ正しいです-しかし、しばしば、それらは間違っています。そして、コンパイラーがますます賢くなるにつれて（または、一部の人々は、sneakierとsneakierと言うかもしれません）、質問の境界は変化し続けます。

したがって、実際には、動作が保証され、長期間動作し続けるコードを記述したい場合は、唯一の選択肢があります。未定義の動作を絶対に避けてください。確かに、あなたがそれに手を出すと、それはあなたを悩ませるために戻ってきます。

あなたの例が考慮していないことの1つは、最適化です。 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言いました：

整形式のプログラムを実行する適合実装は、同じプログラムと同じ入力を持つ抽象マシンの対応するインスタンスの可能な実行の1つと同じ観察可能な動作を生成するものとします。ただし、そのような実行に未定義の操作が含まれている場合、このドキュメントでは、その入力を使用してそのプログラムを実行する実装に要件はありません（最初の未定義の操作に先行する操作に関しても）。

一番の答えは間違った（しかし一般的な）誤解です：

未定義の動作は実行時のプロパティです*。それはできません「タイムトラベル」！

特定の操作は（標準で）副作用があると定義されており、最適化することはできません。I / Oを実行する操作、またはvolatile変数にアクセスする操作は、このカテゴリに分類されます。

ただし、注意点があります。UBは、前の操作を元に戻す動作を含む、任意の動作である可能性があります。これは、場合によっては、以前のコードを最適化することと同様の結果をもたらす可能性があります。

実際、これはトップアンサーの引用と一致しています（私の強調）：

整形式のプログラムを実行する適合実装は、同じプログラムと同じ入力を持つ抽象マシンの対応するインスタンスの可能な実行の1つと同じ観察可能な動作を生成するものとします。
ただし、そのような実行に未定義の操作が含まれている場合、この国際標準では、その入力を使用してそのプログラムを実行する実装に要件はありません（最初の未定義の操作に先行する操作に関しても）。

はい、この引用は「最初の未定義の操作に先行する操作に関してさえも」とは言っていませんが、これは特にコンパイルされているだけでなく、実行されているコードに関するものであることに注意してください。
結局のところ、実際に到達していない未定義の動作は何もしません。UBを含む行に実際に到達するには、その前のコードを最初に実行する必要があります。

そうです、UBが実行されると、以前の操作の影響は未定義になります。しかし、それが起こるまで、プログラムの実行は明確に定義されています。

ただし、これが発生するプログラムのすべての実行は、以前の操作を実行した後、その効果を元に戻すプログラムを含め、同等のプログラムに最適化できることに注意してください。その結果、先行するコードは、その効果が取り消されるのと同等になる場合はいつでも最適化される可能性があります。そうでなければ、それはできません。例については、以下を参照してください。

*注：これは、コンパイル時に発生するUBと矛盾しません。コンパイラがUBコードが常にすべての入力に対して実行されることを実際に証明できる場合、UBはコンパイル時間まで延長できます。ただし、これには、以前のすべてのコードが最終的にを返すことを知っている必要があります。これは強力な要件です。繰り返しますが、例/説明については以下を参照してください。

次のコードがあること、このコンクリート、メモしておく必要があります印刷fooし、それを次のいずれかの未定義の動作に関係なく、あなたの入力を待ちます。

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

ただし、fooUBが発生した後も画面に表示される保証はないこと、または入力した文字が入力バッファーに存在しないことにも注意してください。これらの操作は両方とも「元に戻す」ことができ、UBの「タイムトラベル」と同様の効果があります。

場合はgetchar()行がありませんでした、それがうラインが離れて最適化されるために法的なことだけならばならばそれは次のようになり区別できない出力からfoo、その後、それを「非やって」。

この2つを区別できないかどうかは、実装（つまり、コンパイラと標準ライブラリ）に完全に依存します。たとえば、別のプログラムが出力を読み取るのを待っている間、ここでスレッドをprintf ブロックできますか？それともすぐに戻りますか？

• ここでブロックできる場合、別のプログラムがその完全な出力の読み取りを拒否する可能性があり、その結果、UBが実際に発生することはありません。

• ここですぐに戻ることができれば、戻らなければならないことがわかります。したがって、最適化することは、実行してからその効果を元に戻すこととまったく区別がつきません。

もちろん、コンパイラは特定のバージョンprintfので許容される動作を認識しているため、それに応じて最適化でき、その結果printf、最適化される場合とされない場合があります。しかし、繰り返しになりますが、これはUBが以前の操作を行っていないことと区別がつかないということであり、以前のコードがUBのために「ポイズニング」されているということではありません。