C言語は、ハードウェアを直接コントロールできる一方で、現代の多くの言語が備えている安全装置がほとんどないため、ときに「危険な言語」とされることもある。だが、そのC言語でも安全性の改善は進んでいる。

　Linuxやオープンソースに関するニュースサイト「LWN.net」は2026年9月28日、「Reducing undefined behavior in the C language」という記事を公開した。フランス・パリで開催された技術カンファレンス「Kernel Recipes」の、マルティン・ユーカー氏による講演を報告したものだ。

　ユーカー氏は生体医工学の教授で、MRI装置を制御する自由ソフトウェアにも取り組んでいる人物だ。また、C言語の標準化委員会「WG14」にも関わっている。

　同氏は、2026年になってもC言語を使う価値は十分にあると主張する。その理由として、移植性や長期的な安定性、コンパイルの速さ、生成されるプログラムの速さを挙げた。また、ソースコードを見ればコンピュータが何をするのか把握しやすく、利用できる開発ツールが多いことも長所だと自身の考えを語る。

　一方、C言語の長い歴史は現在の仕様にも影響している。

　1989年に制定された、C言語で初めて標準化された規格「C89」は、当時存在していたさまざまなコンピュータに対応することが求められた。符号付き整数の表現方法が異なるコンピュータや、メモリを区切って扱う機械、特殊なポインターを使う機械など、ハードウェアにはさまざまな違いがあったため、どの環境でも動作する移植性の高いC言語の規格を作ることは非常に難しかった。

　そこで、C89で採用されたのが、C言語は特定の実機ではなく、抽象機械で動作する言語というアプローチだ。

　抽象機械とは、数式や理論の上だけで動く架空のコンピュータのことだ。物理的なハードウェアを持たず、プログラムがどのように動き、どのような結果を返すべきかを定めるための共通モデルだ。コンピュータで内部処理が異なっていても、外部から観測できる結果が抽象機械と同じならよい。

　この仕組みによって、コンパイラは結果を変えない範囲で命令を省略したり、順番を入れ替えたりして高速化できる。この規格は、コンパイラ実装者に多くの自由度を与えているとユーカー氏は解説する。

　そして、プログラムが移植可能でない処理や、規格で動作を定めていない処理を実行したときに発生するのが未定義動作だ。未定義動作が発生した場合、C規格は処理系に「いかなる要件も課さない」と規定している。

　ユーカー氏によれば、これは独自機能の追加やハードウェアの安全機構との連携、積極的な最適化を可能にし、検出の難しい誤りを実装側が無視できるようにするためでもあったという。

　未定義動作の厄介な点は、問題のある命令だけが予想外の結果になるとは限らないことだ。コンパイラは、未定義動作へ到達する状況そのものを「正常なプログラムでは起こらない」と仮定し、そこへ至る処理まで変更する場合がある。

　ユーカー氏は、条件に応じて外部変数へ「42」または「43」を代入し、その後で割り算を行う関数を例に挙げた。割る数が0なら、整数のゼロ除算となり未定義動作が発生する。そこでコンパイラは「割る数が0の場合を考える必要はない」と判断し、値を選ぶ条件分岐を省略して、常に「42」を代入するコードへ変えることがあるという。

　ただし、外部変数への代入を関数呼び出しに置き換えると事情が変わる。呼び出した関数がプログラムを終了させるなら、その後のゼロ除算は実行されない。この場合は未定義動作が発生しないため、コンパイラが条件分岐を省略することはできない。実際に、この違いを正しく扱えなかったコンパイラもあったという。

　さらに、外部から観測できる「volatile」変数へ書き込んだ後にゼロ除算が置かれている場合、コンパイラが除算を先に実行すると、本来は先に行われるはずの書き込みまで消える可能性がある。

　後の未定義動作が、それ以前の処理へさかのぼって影響するように見えるため、「タイムトラベル」と呼ばれる問題として知られている。

　記事によると、2024年に制定された「C23」では、このような命令の移動を防ぐ規定が加えられた。そのため、ユーカー氏は、こうしたタイムトラベル問題は解消されるとの見方を示した。だが、その一方で、初期化されていない変数の読み出しやポインターの比較など、規格の解釈やコンパイラの実装を巡る問題は他にも残っているという。

　これらの問題を解決するため、標準化委員会は、メモリオブジェクトモデルやメモリ安全性、未定義動作に特化した3つの研究グループを運営している。

　ユーカー氏によると、C言語の規格には現在、およそ100個の未定義動作がある。一方、策定中の次期規格「C2y」の草案では、そのうち45個がすでに削除されたという。C言語の問題の幾つかは未定義動作に関連しているため、同氏は、この削減によって状況は改善していると評価した。

　プログラムに残る問題を見つける手段も増えている。コンパイラの警告や静的解析ツールに加え、実行時に異常を検出するSanitizer、LLMを利用したコード解析、プログラムが正しく動くことを数学的に確かめる形式検証などが使われている。最近では、整数のオーバーフローや解放済みメモリの使用についても、コンパイラが警告できる場面が増えているという。

　またユーカー氏は、C言語のメモリ安全性を3分類し、それぞれについて改善の可能性を説明した。

　「型安全性」は、異なる種類のデータを誤って扱うことを防ぐものだ。注釈やコンパイラの検査を強化することで改善できるという。「空間的メモリ安全性」は、配列などの範囲外を読み書きしないことを指す。コンパイラによる境界検査や、配列の長さを伝える属性が役立つ。

　「時間的メモリ安全性」は、解放済みのメモリを再び使う問題などを防ぐものだ。最も解決が難しく、ユーカー氏は、この点では「Rust」に利点があると認めた。一方、「CHERI」や「Fil-C」などによって、Cの安全性を高められる可能性も示した。

　ただし、こうした規格の変更や検査ツールだけで、C言語がすぐに完全なメモリ安全言語になるわけではない。

　ユーカー氏は、全ての問題を確実に防ぐには、負担の大きい実行時検査か形式検証が必要になると説明した。当面は、危険な機能の使用を制限したC言語と形式検証ツールを組み合わせる方法が、最も高い安全性を実現しやすいとの見方を示している。

　また、同氏は、Cは今も“生きた言語”であり、進化し続けているとまとめた。C23では古い関数定義や過去のコンピュータ向け機能を削除し、オーバーフローを検査できる整数演算などを追加した。C2yでも、配列の要素数を調べる機能や未定義動作の削減が進む。

　すぐに完全なメモリ安全を実現するわけではない。だが、将来は可能性があり、それを実現しやすい環境も整っていくとして、標準化活動への参加を呼びかけた。

　もちろん、およそ100個ある未定義動作が45個減ったとしても、すぐさまC言語が安全な最新言語と肩を並べる存在になるわけではないだろう。だが、今回の講演からは、C言語がその長所を維持しながら、安全性を高めようとする取り組みが続いていることがよく分かる。

　半世紀を超えて使われてきたC言語は、完成して変化を止めた言語ではなく、現在も問題を修正しながら進化している言語なのだ。

上司X：　C言語の未定義動作を減らし、将来的にメモリ安全な言語へ近づけられるかを扱った講演が行われた、という話だよ。

ブラックピット：　C言語って、現在でも改善しているんですねえ。すっかり1970年代の古い言語のまま止まっていると思ってましたよ。

上司X：　そんなワケないだろう！

ブラックピット：　いえ、だって知りませんでしたもの。てっきり、何十年も変わらない化石みたいなものかと……。

上司X：　またそんな言い方を（苦笑）。C言語については、新機能の追加というよりも危険だと言われてきた部分を整理している感じだからな。

ブラックピット：　だからこそ策定中のC2y草案では、約100個ある未定義動作のうち45個も削除されたんですね。

上司X：　そう。だから、今も進化していると言っても過言ではないだろう。

ブラックピット：　じゃあ、すぐさまRustみたいな安全な言語に進化するのですかね？　……って分かってて言ってみました（笑）。C言語はこれからもC言語ですよね。

上司X：　まあ、そうだな。規格が変更されたからといってすぐさまC言語が現代的な言語に生まれ変わることはないだろう。ただ、これまで半世紀以上も必要とされてきた言語だけに、その長所を残したまま、どこまで安全性を高められるかということは追求され続けていくことだろう。長い時間をかけた改修は、まだまだ途中ということだろうな。