原則として未定義の動作

CでもC ++でも、CまたはC ++標準に従って動作が定義されていないこの不正なプログラムは興味深いと思います。

#include <stdio.h>

int foo() {
    int a;
    const int b = a;
    a = 555;
    return b;
}

void bar() {
    int x = 123;
    int y = 456;
}

int main() {
    bar();
    const int n1 = foo();
    const int n2 = foo();
    const int n3 = foo();
    printf("%d %d %d\n", n1, n2, n3);
    return 0;
}

私のマシンでの出力（最適化なしのコンパイル後）：

123 555 555

この違法プログラムは興味深いものだと思います。スタックメカニクスを示しているからです。CやC ++（Javaなどの代わりに）を使用する主な理由は、ハードウェアやスタックメカニクスなどに近いプログラムにするためです。

ただし、StackOverflowでは、質問者のコードが初期化されていないストレージから誤って読み取る場合、最も頻繁に投票された回答が、動作が未定義であるという影響に対するCまたはC ++（特にC ++）標準を常に引用します。これはもちろん、標準に関する限り当てはまります（動作は実際に未定義です）。ただし、ハードウェアまたはスタックの機械的観点から、特定の未定義の動作（たとえば、上記の出力）が発生した可能性があり、まれであり、無視される傾向があります。

未定義の動作にはハードドライブの再フォーマットが含まれる可能性があることを示唆した回答を1つ覚えています。上記のプログラムを実行する前は、あまり心配していませんでした。

私の質問はこれです： 未定義の動作を理解することよりも、CまたはC ++で動作が未定義であることだけを読者に教える方が重要なのはなぜですか？ つまり、読者が未定義の動作を理解した場合、それを回避する可能性は高くなりますか？

私の教育は電気工学であることを起こる、と私は建物の建設エンジニアとして働き、そして最後の時間は、私はプログラマーとしての仕事だったそれ自体が、私はより多くの、より従来とユーザーの視点を理解することは好奇心ので、1994年だったが最近のソフトウェア開発の背景。

Frama-Cの値分析は、Cプログラム内のすべての未定義の動作を見つけることを目的とする静的アナライザーで、割り当てconst int b = a;を問題ないと見なします。これは、memcpy()（通常unsigned char、仮想配列の要素に対するループとして実装され、C標準がそのように再実装することを可能にすることを意図して）をstruct（パディングおよび初期化されていないメンバーを含むことができる）にコピーするための意図的な設計決定です別の。

「例外」はlvalue = lvalue;、変換が介在しない割り当て、つまり、メモリロケーションのメモリスライスを別のメモリスライスにコピーする割り当ての場合のみです。

私（Frama-Cの値分析の著者の1人）は、検証済みのCコンパイラーCompCertで選択する定義について彼自身が疑問に思っていたときに、Xavier Leroyとこれについて話し合ったため、同じ定義を使用することになった可能性があります。私の意見では、C標準がトラップ表現である可能性のある不確定な値を使用して行うこと、およびトラップ表現unsigned charがないことが保証されている型よりもきれいですが、CompCertとFrama-Cはどちらも比較的非エキゾチックなターゲットを想定しています。そしておそらく、標準化委員会は、初期化されていないものintを読み取ることが実際にプログラムを中止する可能性があるプラットフォームに対応しようとしていました。

戻るb、または渡しn1、n2またはn3にprintfそれを初期化することはありませんメモリの初期化されていないスライスをコピーするので、未定義の動作と考えることができ、少なくとも最後に。古いFrama-Cバージョンの場合：

$ frama-c -val t.c
…
t.c:19:… accessing uninitialized left-value: assert \initialized(&n1);

そして、古いバージョンのCompCertでは、プログラムを受け入れられるように少し変更した後：

$ ccomp -interp t.c
Time 33: in function foo, expression <loc> = <undef>
ERROR: Undefined behavior

未定義の動作は、最終的には動作が非決定的であることを意味します。非決定的なコードを書いていることに気づいていないプログラマーは、単に無知なプログラマーです。このサイトは、プログラマーをよりよくする（そして無知を少なくする）ことを目的としています。

_{非決定的な動作に直面して正しいプログラムを書くことは不可能ではありません。ただし、これは特殊なプログラミング環境であり、異なる種類のプログラミング規則が必要です。}

あなたの例でも、プログラムが外部から発生した信号を受信した場合、「スタック」の値は、期待した値が得られないように変化する可能性があります。さらに、マシンにトラップ値がある場合、ランダムな値を読み取ると、何か奇妙なことが起こる可能性があります。

未定義の動作を理解することよりも、CまたはC ++では動作が未定義であることだけを読者に教える方が重要なのはなぜですか？

特定の動作は、再構築せずに実行から実行まで、再現性がない場合があるためです。

何が起こったかを正確に追跡することは、特定のプラットフォームの癖をよりよく理解するための有益な学術的演習かもしれませんが、コーディングの観点からは、関連するレッスンは「それをしないでください」だけです。のような表現a++ * a++は、コーディングエラーです。それは本当に誰もが知る必要があるすべてです。

「未定義の動作」は「この動作は確定的ではありません。コンパイラやハードウェアプラットフォームによって動作が異なるだけでなく、同じコンパイラの異なるバージョンでも動作が異なる場合があります。」の省略形です。

ほとんどのプログラマーは、特にCおよびC ++が標準ベースの言語であるため、これを望ましくない特性と見なします。つまり、標準に準拠したコンパイラーを使用している場合、言語仕様が言語の動作について特定の保証を行うため、それらを部分的に使用します。

プログラミングのほとんどのことと同様に、長所と短所を重み付けする必要があります。UBである操作の利点が、プラットフォームに依存しない安定した方法で動作させることの難しさを超える場合は、必ず未定義の動作を使用してください。ほとんどのプログラマーは、ほとんどの場合、それは価値がないと思います。

未定義の動作に対する救済策は、特定のプラットフォームとコンパイラを前提として、実際に得られる動作を調べることです。この種の試験は、Q＆Aの設定でエキスパートプログラマーが探索する可能性のある試験ではありません。

特定のコンパイラのドキュメントに、標準で「未定義の動作」と見なされるコードを実行した場合の動作が記載されている場合、その動作に依存するコードは、そのコンパイラでコンパイルすると正常に動作しますが、次の場合は任意に動作する可能性があります。ドキュメントに動作が指定されていない他のコンパイラを使用してコンパイルされた。

コンパイラのドキュメントに、特定の「未定義の動作」の処理方法が指定されていない場合、プログラムの動作が特定の規則に従っているように見えるという事実は、同様のプログラムの動作については何も述べていません。さまざまな要因により、コンパイラーは予期しない状況を異なる方法で処理するコードを発行する可能性があります。

たとえば、intが32ビット整数であるマシンを考えてみます。

int undef_behavior_example(uint16_t size1, uint16_t size2)
{
  int flag = 0;
  if ((uint32_t)size1 * size2 > 2147483647u)
    flag += 1;
  if (((size1*size2) & 127) != 0) // Test whether product is a multiple of 128
    flag += 2;
  return flag;
}

もしsize1およびsize2どちらも46341（製品は2147488281）と同じでしたが、関数が3を返すことが予想されますが、コンパイラは最初のテストを完全にスキップできます。製品が十分に小さいため、条件が偽になるか、次の乗算がオーバーフローし、コンパイラーが何かを行う、または行ったことのある要件を緩和します。このような動作は奇妙に思えるかもしれませんが、一部のコンパイラ作成者は、そのような「不要な」テストを排除するコンパイラの機能に大きな誇りを持っているようです。一部の人々は、2番目の乗算のオーバーフローが、最悪の場合、その特定の積のすべてのビットを任意に破損させることを期待するかもしれません。しかし実際には