CおよびC++における未定義動作の遍在性
数十年にわたり、CおよびC++はシステムのプログラミングの基盤となってきました。そのパフォーマンスとハードウェアへの近接性が高く評価されています。しかし、21世紀が進むにつれ、深刻な現実が浮き彫りになってきました。真に「正しい」CまたはC++を書くことは、ほぼ不可能です。言語仕様は未定義動作（UB）に満ちており、数十年の経験を持つエキスパートプログラマーでさえ、標準に違反するコードを生成してしまう可能性が高いのです。
これは単なる学術的な衒学主義の問題ではありません。現代のコンパイル環境において、UBは、壊滅的な失敗、セキュリティの脆弱性、そしてデバッグがほぼ不可能な論理バグを引き起こす可能性のある、静かな殺し屋です。
明らかなもの以上に：UBが実際に意味すること
ほとんどの開発者は、二重解放（double-free）、使用後解放（use-after-free）、配列の範囲外アクセスといった「大きな」UBの落とし穴に精通しています。C/C++はメモリ安全な言語ではないため、これらは想定されるリスクと見なされています。しかし、UBは最適化が有効な場合にのみ重要であるという誤解が根強く残っています。高い最適化レベルがなければ、コンパイラは敵対的にUBを「利用」することはないと信じている人もいます。
これは根本的な誤解です。UBは、コンパイラが積極的にあなたのコードを壊そうとしていることを意味するのではありません。それは、コンパイラがあなたのコードが有効であると仮定することを許可されていることを意味します。プログラマーがUBを導入すると、本質的にコンパイラに対して「この状態は決して起こり得ない」と伝えていることになります。その結果、コンパイラは、その意図が言語のルール内で法的に表現されていなかったために、必要なチェックを省略したり、プログラマーの実際の意図を無視したコードを生成したりすることがあります。
あるコミュニティメンバーが次のように指摘しています：
コンパイラはUBコードが起こらないことを期待しているため、もしあなたがどうしてもUBコードを書いたとしても、コンパイラ（特に最適化器）は、それを自身のハッピーパスにとって都合の良いものとして翻訳することを許可されています。
見えない地雷原：一般的なUBの例
UBはメモリ破壊よりもはるかに広範囲に及びます。それは、最も日常的な操作の中に隠れています。
アライメントとポインタのキャスト
整数ポインタをデリファレンスする単純な関数は、ポインタが正しくアライメントされていない場合（例：sizeof(int)の倍数ではない場合）、UBを引き起こす可能性があります。x86アーキテクチャはアライメントされていない読み取りに対して非常に寛容であることで有名ですが、SPARCやAlphaのような他のアーキテクチャでは、SIGBUSを発生させるか、カーネルによるエミュレーションが必要となり、パフォーマンスを低下させたりプログラムをクラッシュさせたりすることがあります。
極めて重要なのは、UBはしばしばデリファレンスの前に発生することです。バイトバッファ（ネットワークパケットなど）を整数ポインタに直接キャストすることは、しばしばUBとして挙げられます。なぜなら、コンパイラがセキュリティタグ付けやガベージコレクションのために、ポインタの下位ビットに特定の意味を割り当てることがあるからです。
標準ライブラリの落とし穴：isxdigit()
標準ライブラリの関数でさえ、罠となることがあります。isxdigit()関数は、unsigned charとして表現できるint、またはEOFの値を期待します。もし、charが符号付きであるシステムにおいてプログラマーがcharを渡した場合、0-127の範囲外のあらゆる値は負の整数になります。もしisxdigit()の内部実装が、負の値のチェックなしに、入力を配列のインデックスとして使用している場合、範囲外のメモリ読み取りにつながり、組み込みシステムではI/Oマップされたメモリをトリガーする可能性があります。
浮動小数点数の変換
floatをintに変換することは、UBの頻繁な原因となります。C23標準に従えば、もし浮動小数点数の整数部分が対象の整数型によって表現できない場合、その動作は未定義となります。これには非有限値（NaNまたはInfinity）も含まれます。
floatを整数に安全に変換するには、開発者は有限性と範囲の境界に関する広範なチェックを実装しなければなりません。これは、単一のキャストに見えるタスクに対して、膨大な量のボイラープレートが必要となる作業です。
ヌルポインタのパラドックス
ほとんどの開発者はNULLはアドレスゼロであると想定していますが、C標準はNULLがゼロと等しいと比較できることのみを保証しています。ヌルポインタのデリファレンスは、UBの典型的な例です。さらに、構造体をゼロクリアするためにmemsetを使用することは、技術的にはポインタメンバがプラットフォームのNULL値に設定されることを保証しませんが、ほとんどの現代的なシステムでは動作します。
進むべき道：人間の専門知識 vs. AI
C23標準には「undefined」という単語が数百回も登場するため、大規模なコードベースをUBの観点で手動で監査することは、圧倒的な作業量になります。ここで、大規模言語モデル（LLM）が驚くべき有用性を示しています。LLMは、不適切なprintfの書式指定子やアライメントの問題など、人間がレビューアーとして見落としてしまうような微妙なUBを特定する能力があることが多いです。
such as incorrect printf format specifiers or alignment issues - human reviewers miss.
しかし、これは新しい緊張を生じさせます。AIがこれらのバグを見つけることはできますが、修正を確定させるには、依然として専門的な知識を持つ人間が必要です。業界がシフトするにつれ、AIにUBを「修正」させることは、根本的なアーキテクチャ上の含意を完全に理解せずに、潜在的に新しく、より微妙なバグを導入するリスクがあります。
結論
現代の時代において、厳格なツールと監督なしにCまたはC++を書くことは、ますます無責任であることが増えています。人間がコードを読み、現代のコンパイラがそれを解釈する方法との間のギャップが大きくなりすぎています。メモリ安全な言語の採用、またはLLM駆動の型監査による統合、のいずれかを通じて、業界はCの抽象マシンにおけるシステム的な不安定性を解決する方法を見らなければなりません。