最近の検索
検索オプション
結局 UB を乱用/悪用 (abuse) するのがユーザになるのかコンパイラになるのかという話になりそうで、そもそも「ユーザがコントロールできるべき領域」は明確に規格で決まっているわけなのだから、コンパイラが UB を滅茶苦茶にしたからといって「ユーザに与えるべきコントロールがコンパイラに奪われている」とは言えないのではないか、と思います
あるいは特定の従来 UB だった挙動をユーザが制御できるべきなら、規格でそう定めるようにするのが正道だと思っている
「ユーザが腐ったコードを書けること」の尊重をコンパイラにどこまでさせるか、というのがひとつの大きな論点だと感じられており、私は「ユーザがどんなにセキュリティやパフォーマンスやビジネスを気にしていようが、規格を逸脱しないことはユーザの責任で、ユーザの逸脱を積極的に容認する方向性には特に慎重にすべき」という立場です
で、コンパイラが合理的な範囲でユーザによる逸脱の通知を努力しているという前提なら、「ユーザが逸脱してこない領域の未定義動作をどう扱おうが処理系の勝手」は道義的に問題ないと思う。
最適化としてお粗末だというのは少なくとも「最適化」として不適だと批判する理由にはなるだろうけど、「未定義動作の使い方」として不適だと批判する理由には使いづらいかなと。
たぶん氏と見解が一番違うのは「じゃあついでに最適化に使ってみるか！」を許容するかどうかだと思うけど、私は悪意をもって破壊するようなコードを仕込むのでもなければべつによくないか？ というくらいの考えです。最適化なんてむしろ善意だからね。
https://mastodon.cardina1.red/@lo48576/113530022605721758
ただし「悪意のない素朴な UB の発現」も結局文脈次第で普通に致命傷 (脆弱性、永続データの破壊、 etc.) になりうるので、その点では「影響が大きいかどうか」さえ気にすることの意味は薄く、本当に悪意があるかどうか (たとえば C: ドライブをフォーマットしようとするか) 程度のことしか気にする意味ないんじゃないかなと思っています。
最適化で傷口が広がるとかについては「傷口は開く場所が問題だし駄目なときは駄目だから、深かろうが浅かろうが『開いた時点で負けてる』という事実を受け入れよう」という感想。
いやもちろん「それでもできるだけ傷口を浅くして人々を救済したい」という理想を持っている人々が多いのは知ってるけど。
Panic を恐れるべからず - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2019/12/19/dont-fear-the-panic/#inconsistency-bugs-and-recoverability
この記事でもその態度は出ていて、「傷が開いた時点でもう駄目、傷口の深さを気にするよりも怪我の原因を探せ」というスタンス。
こういう類の諦念を含む悲観を私は「敗戦後的世界観」と呼んだりしている (<https://x.com/lo48576/status/1341305332362964992>)。