プログラマーがソースコードで明示的に示したコードパスを削除するのは、属性が付けられていない限り、厳しいコンパイルエラーにすべきだと思う（誰かCにunsafeキーワードを追加したい人いる？）。別のコメント者がLLMを使うことを提案してたけど、私は反対。clangdがチェックされてない操作（例えば、符号付き加算）に対して警告を出すのは良いスタートだと思う。

この道の一例として、すべての関数は終了するか副作用を持たなければならないってことがある。まだ私にはその影響は出てないけど、無限ループや再帰を書いちゃって関数が削除される可能性は十分にあるよね。あと、末尾再帰にボーナスポイント。デバッグ中に無限ループに引っかからなければ、このバグは高い最適化レベルでしか現れないかもしれない。

そうだね、クラッシュは最も無害な未定義動作の一つだよ。少なくとも目に見えるからね。もっとひどい場合だと、プログラムが静かにゴミデータを処理し続けたり、ハードディスクをフォーマットしたり、攻撃者に鍵を渡しちゃうこともある。

記事の「最適化の話じゃない」というポイントがすごく気になった。以前、変換パイプラインの最後に実行されるという前提で分析パスを書いたことがあって、これが正しさのために必要だったんだ。その前提は、これ以上の最適化が行われないから安全だというものだった。今はちょっと自信がなくなってきたな…。

それは問題じゃなくて、機能なんだよ。

そう、それは問題だけど、UBの最も有用な機能でもあるんだ。単に定義したり未定義にすることを提案する人は、コンパイラがプログラムの全体の部分を削除できることがポイントだってことを見落としてる。特定の入力に対してUBになるコードを書くときは、その入力に対してプログラムがどんな挙動を持つことも意図していないからなんだ。だから、コンパイラにはそれらを最適化してほしいし、他の定義されたケースの挙動から影響を受けることをしてほしい。ログ文字列をトリガーする条件を追加して、それがバイナリに現れないのを見るのはすごく満足感があるよ。なぜなら、それらはUBを通じてしか到達できないから。

どう悪いの？それは本当なの？もしそうなら、超ヤバいじゃん。

同意だね。これらはポータブルなコードを書くときに避けるべき標準的なことばかりだし（アドレス0のオブジェクトにアクセスするみたいに、必要ないこともある）。自分が好きなように書いて、どんな環境でも同じように動くことを望んでいる人からの意見に聞こえるよ。そういう言語にすることは、プラットフォームに合わせて書けるという利点を失うことになる。

その例は間違いなくUBだよ。これを正しく考えるには、UBがあるときは言語標準の範囲外にいるってことを理解することが大事。しばらくは問題なく動くこともあるし、無限に動くこともある。でも、実際にはツールチェーン（コンパイラの入れ替えやアップグレード）、アーキテクチャ、ランタイム（libcのバージョン差）に振り回されることになる。結局、砂の上に基盤を築くことになるんだ。それがUBの危険性だよ。

全然違うよ。まず、スタック領域が超えたときに何が起こるかを定義できるし、すべてのプログラムが無制限のスタック領域を必要とするわけじゃない。事前に計算できる一定の量だけで済むプログラムもあるしね。（それに、実装によってはスタックを全く使わない言語もある。）君の言語も、残りのスタック領域を調べるツールを提供したり、それに基づいて保証をすることができるかもしれない。あるいは、スタック領域が足りなくなったときの処理を設定できるようにすることもできる。

入力に基づく未定義動作は、悪用される可能性があるよ。

Ada 83では、コールスタックのオーバーフローに関して未定義動作はないよ。リファレンスマニュアルから引用すると、「STORAGE_ERROR この例外は、以下のいずれかの状況で発生します：(...) または、サブプログラム呼び出しの実行中に、ストレージが不十分な場合。」

うん、この記事はまさにFUD（恐怖、不確実性、疑念）の定義だね。

-受け入れ： 「ただ未定義動作を書かないで。」もっとまともな言語に切り替えればいいじゃん。私がRustの信者だと攻撃される前に言っておくけど、Javaのことを言ってるんだよ :P 基準が低すぎて、地球の中心近くに浮いてるみたい。

ここに作者がいます。 > -受け入れ:「ただUBを書かないで。」私の記事のポイントは、これは不可能だということです。人間がコードを書く限り、これが最終的な状態にはなり得ません。C/C++でUBを書くのを避けられる人間はいません。

「ただコンパイラに未定義を定義させる」段階ってどの段階ですか？アラインされていないアクセス？パックされた構造体。コンパイラは魔法のように正しいコードを生成します。まるで最初から正しくやり方を知っていたかのように！実際、常に正しいやり方を知っていたんです。ただ、やらなかっただけ。厳密なエイリアス？ユニオン型のパニング。重要なコンパイラでは動作することが文書化されていますが、聖なるC標準はそれを言っていません。あるいは、単純に無効にしちゃうのもあり：-fno-strict-aliasing。好きなようにメモリを再解釈して楽しんでください。ここかしこで鋭い部分にぶつかるかもしれませんが、コンパイラから来ることは絶対ないです。オーバーフロー？ただ定義しちゃえばいい：-fwrapv。ついでに+、-、を__builtin__overflowに置き換えれば、明示的なエラーチェックも無料で手に入ります。いい機能的インターフェースだし、効率的なコードも生成します。「受け入れ」段階は実際には「正気の人はC標準なんて気にしない」ってことです。標準はゴミ、コンパイラだけが重要です。そして、コンパイラにはほとんどすべての問題を回避できる非常に便利な機能がたくさんあることがわかりました。人々は「ポータブル」な「標準」Cを書きたいから、これを使わないだけです。本当の受け入れは、その考え方から抜け出すことです。なんとかして、私はフリースタンディングCで完全なLispインタープリタを作り上げ、上記の論理に従うだけでUBSanを通過させることができました。最初は本当に驚きました。クラッシュすると思ってたのに、全然大丈夫でした。だから、私ができるなら、誰でもできるはずです。

Cでは、受け入れは「UBを書くことになるし、最終的には何か悪いことが起こる」ってことです。

-否認:「自分のマシンでの符号付きオーバーフローがどうなるかは知ってる。」それとも、Cの言語哲学やUBの理由が書かれた導入ページを飛ばさないで読んでみたら？確かにUBは難しいこともあるけど、最初の4つのステップは全く必要ないよ。それは、使っている言語のコアコンセプトを実際に理解していないことを意味していて、ちょっとバカみたいだね。

それは明らかだよね。アライメントが合ってないアドレスから整数を読み込むことはできないし、Cレベルだけの問題じゃない。アーキテクチャ間での機械語の保証もないしね。

それは全然問題ないし、普通のプログラマーなら当然のことだよ。ポインタのキャストは明らかに危険な領域だし。

ここに作者がいます。 > アラインされていないポインタ自体は未定義動作（UB）です。そうですね。「実際、それはその前からUBでした」という部分に書いてあります。 > UBはハードウェアに関係ないし、クラッシュやエラーとも無関係です。そうそう、これも伝えようとしたんだけど、「でも、明らかに大丈夫だよ」と言う人たちにも例を挙げて説明してるんです。だって、そうじゃないから。

ってことは、#pragma pack(push, 1)で構造体を持ってる場合、アライメントが合ってないメンバーへのポインタを使えないってこと？

記事のポイントは、実際にはUB（未定義動作）に遭遇するために変なことをする必要はないってことだと思う。多くの人がCやC++は「すごく柔軟」だと勘違いしてるけど、実際は「やりたいことができる」だけじゃなくて、ほとんどの派手で強力なことはUBの絶対的な地雷原なんだよね。

そう、そこにはデータレースがあります。volatileの値は、現在のスレッドの外部で変更される可能性があります。それがvolatileの意味であり、存在理由です。編集: スレッド=実行のスレッドです。プログラム内のスレッドセーフについて言ってるわけじゃないです。

それは、非順序操作の概念を許可する限りは意味があるよ（確かにそれは少し珍しいけど；例えばSchemeではそういうものは順序で発生することが定義されているけど、どの特定の順序かは未定義で、毎回違う可能性がある）。「volatile」アノテーションは、変数をMMIOレジスタかその類のものとしてマークするもので、コンパイラの制御を超えた理由でいつでも変わる可能性があるものを示してる。もちろん、これには同時変更の危険が潜んでいる。とはいえ、「データレース」の「一般的な言葉」での定義はC標準で使われている定義とは違うから、最後の文は標準Cの議論では誤解を招くことになるよ。 > プログラムの実行は、異なるスレッドでの2つの対立するアクションを含む場合、少なくとも1つはアトミックでなく、どちらも他の前に起こらない場合、データレースを含む。こうしたデータレースはすべて未定義の挙動を引き起こす。（ここで「対立する」と「他の前に起こる」は前のテキストで定義されている。）

マイクロコントローラの周辺機器からレジスタを読み取ると、リセットされる可能性があるっていうのがここでの副作用の一例だね。そういう時にvolatileを使うんだ。

ボラティル（volatile）だと、リードの間に割り込みサービスルーチンで変更される可能性があるから、納得できるね。

ボラティルはシステムハックみたいなもんだよ。もっとちゃんとした修正をすべきだったし、現代の言語が「Cがやったから良いアイデア」みたいに振る舞うのはおかしい。ハックの理由は、初期のCコンパイラが常にスピル（spill）するから。だから、MMIOドライバコードを書くときにポインタをMMIOハードウェアに向けると、実際に動くんだ。xを変えるたびにCPU命令がメモリ書き込みを行うからね。Cコンパイラが基本的な最適化を行うようになると、その「賢い」トリックは機能しなくなる。コンパイラはxを何度も変更していることが分かるから、レジスタからxをスピルしなくなって、ドライバが正しく動かなくなる。Cの「volatile」キーワードは「コンパイラよ、その最適化を忘れろ」って言ってるハックで、実装には数分で済んだんだろうけど、MMIOのインストリンシックを関連ライブラリで提供する正しい修正はかなりの手間がかかる。インストリンシックが必要な理由は、実際に何が可能で何が不可能かを明示できるから。特定のターゲットでは1バイト、2バイト、4バイトの書き込みができるから、これらは異なる操作でハードウェアもそれを理解してる。例えば、あるデバイスが4バイトのRGBA書き込みを期待している場合、4つの1バイト書き込みを出すと混乱を招いて、動かないかもしれないから、やらない方がいい。特定のターゲットではビットレベルの書き込みも可能で、「0x1234のアドレスのビット4にMMIO書き込み」と言えば、単一のビットを書き込むことができる。ボラティルだけでは、何が起こるのか、何を意味するのか分からないんだ。

ここで書いてるのは私だよ。> ほんの表面をなぞるだけだね。 そう思う。この記事のポイントは、標準で「未定義」と使われている283の使い方を列挙して説明することじゃない。省略によって未定義になるものをすべて列挙することでもない。この記事のポイントは、それらを避けることは不可能だってこと。少なくとも、1972年にCが発明されて以来、誰もそれを避けられなかった。54年間成功してないのに、「もっと頑張れ」とか「ミスをしないようにしろ」ってのは、少なくとも解決策じゃない。MythosがOpenBSDで見つけた（唯一の！）悪用可能な欠陥は、OpenBSDの開発者たちにとって素晴らしい証拠だったけど、投稿でも言ってるように、私は彼らのコードの中で一番シンプルな部分を指摘して、たくさんのUBを見つけた。さて、findがwaitpid(&status)の前に初期化されていない自動変数status（UB）を読み取るのは悪用可能なのか？（報告されてない）そんなアーキテクチャやコンパイラは想像できないな。要するに、> 以下は世界中のすべてのUBを列挙しようとする試みではない。UBはどこにでも存在するってことを示してるだけで、誰もそれを正しくできないなら、プログラマーを責めるのは公平なのか？私の言いたいことは、すべての非自明なCとC++コードにはUBがあるってこと。

直感的にはそうだね。プログラムはB入力が渡されないかのようにコンパイルされるし、それにはB入力を検出しようとするコードを排除することも含まれるかもしれない。

そうだね、いいまとめだ。

生産環境が全く異なるアーキテクチャかもしれないから、こういう詳細はめっちゃ重要だよね。「私のマシンでは動く」は、実際のターゲットがど田舎の携帯電話塔の上にある小さな組み込みシステムだったら役に立たない。確かに、ほとんどの人はそんなことやってないと思うけど、ここにいる開発者の大半はウェブ開発者だろうし、それでも自分が遭遇したことがなくても面白い議論だと思う。むしろ、そういう場合こそ興味深いかも。

コンピュータは昔はクールだったけど、今は危険だね。どの会社も安全性や露出（ニュースに出ること）についてうるさく言ってるから、「危険」への批判がすごいことになってる。新しい世界は、自然を見たことがない都会の人たちの集まりみたいで、芝刈り機を見せるとパニックになる。回転する刃?!?!?! まじで狂ってる！！

カラフルな比喩や驚くような挙動の例を引き出す機会なのかな。あと、常に議論を巻き起こすテーマでもあるしね。

え、何それ？20年前にCとC++を書いてたけど、その頃もUBは会話（やカリキュラム）の大きな部分だったよ。GCC 3.2の周りにはいくつかの有名な「スキャンダル」があった（確か）けど、コンパイラが最適化でUBをもっと積極的に使い始めたから、多くの人が長い間GCC 2.95を使い続けた理由でもあった。GCC 3.2は2002年に出たよ。

UBがなかったら、プログラマーは何をするんだろう？デバッグや修正することが足りなくなっちゃうの？

Hacker Newsは、実際にプログラミングするよりもプログラミング言語に興味がある人向けに偏ってる気がする。多分、Y-combinatorのLispの影響かな。新しいプログラミング言語の開発や使用が世界で最も魅力的だと思ってるCS卒の少数派もいるし、そういう人たちはその考えを持ち続けてるんだろうね。そういう人たちが言語のデザイン面にも興味を持つのは自然なことだし、CのUBもその分野に入る。だけど、元々は古いCPUアーキテクチャに合わせてパフォーマンスをあまり損なわないようにしてた部分が多いと思うし、車輪が丸いのと同じくらい「デザインの選択」って感じだよね…。

Rustの台頭以降、もっと注目されるようになったのかな？でも、昔からCに興味を持ってた人もいたよね。俺も、C標準についてお互いにペダントを競い合うような、どうしようもないIRCチャンネルにいたことがある。君の歴史的なCの使い方は、もっと生産的だったと信じてるよ。

そんなに簡単だったらいいのにね：https://silentsblog.com/2025/04/23/gta-san-andreas-win11-24h... 本当の答えは、Cのような言語の支持者がUBの危険性や修正の難しさを完全に無視しているように見えることだね。Rustの支持者は逆にそれを過大評価してるし。無意味な争いやドラマは読むのが楽しいし、クリックも増えるからね。

天と地には、ホレイショ、君の哲学で夢見られている以上のことがある。君は多分、何年も形が悪いコードを量産してきたんだろうね。今、君は自分の欠点に気づき始めてる。これは通常、中級から上級プログラマーへの移行と見なされるよ。

この記事を書いてる人たちのほとんどは、実際にはC言語の仕様を知らないし、そのデザインも理解してないんだよね。Cで3つの重要な概念をしっかり理解すれば、何が未定義動作（UB）を引き起こすか簡単に見分けられる。具体的には、1) 表現 2) 文 3) シーケンスポイントと「単一更新ルール」。ここで詳しく書いたから、さらなる読み物のリンクもあるよ - https://news.ycombinator.com/item?id=48144734

特にx86では、問題を引き起こさないと仮定されている。

これがCじゃなくてC++だって指摘しようと思ったけど、確認したら実際にはstd::atomicって書いてあったんだ！atomic_intじゃなくてね。