「らりお生きていけないよおおおお」
らりお48歳
武器 なし
弾薬 なし
戦闘能力 なし
……
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿 「らりお生きていけないよおおおお」
らりお48歳
武器 なし
弾薬 なし
戦闘能力 なし
……
キオクシア、不採算部門を切り離したのか採算部門だけ救済したのかわからなくなってきたな (?)
土曜日が祝日だと振替休日が発生しないの、感謝が足りない。勤労感謝は休業日の顔をしているぞ。
因果を無視して言うと「キオクシアが不採算部門の東芝 (その他部門) を切り離せた」が雰囲気一番近そう (?)
「こういうことをしたいんだけど……」的なスレッドに全然本題ではないのに「バックアップをお忘れなく」とだけコメントしていく連中なんなんだ、俺も「食事をお忘れなく」とか「水を飲むのをお忘れなく」とかコメントした方がええんか？
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
長時間の外出になる場合は読むのに時間のかかる専門書の類と娯楽小説をペアで持っていくようにしている
それはそれとして現代だとｲﾝﾀﾈｯﾂ小説を無限に読めるので良い時代ですね
言うて商業出版の小説も大外れ引いたらﾊｧとなるので、ｲﾝﾀﾈｯﾂ小説は身軽に離脱することを心掛けていれば割とどうにかなる
https://mastodon.cardina1.red/@lo48576/113456640650248342
最近 Android 搭載で普通にアプリが動く電子ペーパーが気になっているのもﾈｯﾂ小説向けを考えてです
布団で横になって使うなら10型はちょっとデカすぎるので BOOX Palma 2 とかも候補に入ってくる
Who’s the better dancer? : r/Genshin_Impact
https://www.reddit.com/r/Genshin_Impact/comments/12ug6kc/whos_the_better_dancer/
その発想はなかった
sizeof で配列サイズとポインタサイズを間違えたりするのは定番ね
個人的に C の流儀 (常識ではない) で謎なのが、 return を関数風に return(0); みたいに書く人の存在。
他の演算子と違って括弧がない場合に曖昧さの発生する部分なんてないと思うんだけど、得るものあるか？
C で中級者以上に圧倒的に多い誤りは strict aliasing rule への違反だと思うのだが、なんとこれは未定義動作でしかも警告が極めて出づらいものなので、数の多さに反して誰も気付いていない
monicahq/monica: Personal CRM. Remember everything about your friends, family and business relationships.
https://github.com/monicahq/monica
個人用の CRM ってやつを homelab に立てたので、以後人間関係の記憶はこちらに投げていく形になります。よかった。
友人関係は大学の中頃以降ほぼ全く広がっていないので全然問題ないのだが (逆に問題がある)、職場の人とかはマジで管理しきれん
しかももう高校の同期とか完全に忘れているので (忘れているというよりは現役時代から既に覚えられていなかったというべきなのだが)、同窓会が非常に心配である
@omasanori ANSI C より前ですか……標準にすらなっていなかった時代の慣習が連綿と受け継がれているとしたらロマンがありますね (いいえ)
@lo48576 return expr; のexprを括弧で囲まなければならなかった時代がある。なので、その時代のコードが形を変えながら残っていたり（AT&T Unixから血統的に繋がっているUnixや*BSDのコードならありえる）、その時代の人々が書いた文書のスタイルを鵜呑みにした人々が再生産していたりするのかもしれない。
宅配の荷物の受取とかでたまに要求される >本名 (名字) の手書き
いま contacts とか持ってる webdav サーバがギリギリ VPS に置いてあるのでまだ大丈夫です (?) (連絡先以上の情報はない)
家燃えたら個人的に蓄積しているほぼあらゆる情報がマジで死ぬので (そして換気が悪くサーバが埃を溜めやすいので) 本気でバックアップをやらないといけない
読書、タスク管理、物品、書類管理情報、メモやログ、人間関係情報、購入したデータ、非公開リポジトリ、本当にほぼすべて
ANSI Cの規格過程で提案されて最終的に入らなかった仕様（言い換えると、K&R CにもANSI Cにも含まれない仕様）の中にnoaliasという型修飾子があり、dmrが激烈に反対して入らなかったことを最近知った。でも、これってC99のrestrictとどう違うんだろうか。
無料で EAX がもらえる (これは嘘で、未定義動作) (最近はコンパイラがエラー出してくれそう)
UB は undefined behavio(u)r ですね。C/C++ ではあまりに当たり前かつ頻出なのでいちいち未定義動作と書くのはダルい (?)
とはいえ C/C++ で結果が微妙に保証されていない規定は他にも「処理系定義」とか「未規定の動作」とかいろいろあるので、そういうのと並べるときは日本語で「未定義動作」と書くこともある
よく C/C++ で言われる (むしろ最近は見なくなった (観測範囲の問題？)) 「-O3 はプログラムが壊れるから -O2 までにしておくべき」みたいなのは、本当に壊れているのはプログラムの方で、未定義動作が -O3 でアグレッシブにコンパイルされて意図せぬ挙動に変化しているだけの場合がほとんど。
UB だと何も保証されないので、たとえばコンパイラや標準ライブラリを別のものに変えたりプラットフォームを変えたりコンパイラのバージョンを上げたりコンパイルオプションを変えたり、あるいは単に再コンパイルしたりなど、あらゆる場面で「今まで動いていたのに新しいバグが発生した」のような状況になりうる。しかも再現も難しい
ISOではなくIECの方のウェブストアではなぜかC90を紙で注文できることに気付いたので生まれて初めて国際規格の規格書を注文してみたんですが、装丁があまりにも、あまりにもだった。
いや、規格書に何を求めているんだって話ではあるんですが、でも200ページちょいで18,993 JPY（送料込み）だからもうちょっとこう、あるよなぁ？！という気持ちがある。2024年のomasanoriマストノットバイはこれです。
https://x.com/FFmpeg/status/1858654093985935740 #tw
FFmpeg も「A major blocker to free and open source multimedia is @isostandards.」と言っている
https://x.com/FFmpeg/status/1858655192947786045
> .@isostandards will argue that the authors of standards need to be paid. But in reality they pocket the money and the authors of standards get $0
そんな……
表紙だけでなく「ペーパーバック」の全体的な紙質の悪さみたいな話もたまに聞くわね
UB、まあそんなもんかという気持ちだったけど、最近“What every compiler writer should know about programmers, or, “Optimization” based on undefined behaviour hurts performance”を読んでUBを理由に最適化するCコンパイラのアンチになった。規格にUBがあるのは仕方ない（コンピューターアーキテクチャによって望ましい挙動が違うことがあるので）けどUBを理由にDCEとかやるのはよくない派になったということです。
Falsehoods programmers believe about undefined behavior
https://predr.ag/blog/falsehoods-programmers-believe-about-undefined-behavior/
https://x.com/RCS/status/1560717470620590081 #tw
> USING SIGNED INTEGERS TO ACHIEVE PERFORMANCE GAINS FROM UNDEFINED BEHAVIOR IS EVEN DUMBER THAN OMITTING REQUIRED CODE TO MAKE YOUR PROGRAM FASTER.
思い出してゲラゲラ笑っています
Krister Walfridsson’s old blog: Why undefined behavior may call a never-called function
https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html
Undefined Behavior deserves a better reputation
https://www.ralfj.de/blog/2021/11/18/ub-good-idea.html
Do we really need Undefined Behavior?
https://www.ralfj.de/blog/2021/11/24/ub-necessary.html
> To avoid ambiguity, I will refer to the above notion of UB as “unrestricted UB”. The alternative interpretation of UB promoted by Yodaiken is what one might call “platform-specific UB”.
unrestricted UB と platform-specific UB という分類、話がしやすくなりそうで良い
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
生態系とか湿度とか地震の有無による建築物の違いとか、いろいろ歴史的・地理的な事情は絡んでいそうだけど
この記事の内容は妥当だと思うんだけど、その上でコンパイラはUBを積極的にコード変形の理由に使うべきではないという立場です。
https://predr.ag/blog/falsehoods-programmers-believe-about-undefined-behavior/
規格の言い回しでいうと、strictly conforming programとconforming programというのがあって、strictly conforming programはany unspecified, undefined, or implementation-defined behaviorに依存しない（かつ、any minimum implementation limitを超えない）コードのことで、コードを書く側の心構えとしてはstrictly conforming programを目指すべきなのだけれども、コンパイラを書く側の心構えとしてstrictly conforming program以外は好きに壊していいのか？それは少し違うんじゃないか？というのが今の気持ちです。
うーん、気持ちとしては同意したいところがあるけど、最適化がどこまで自明であるかというのは線引きがそうとう難しいのではないかという気持ちがある
たとえば strict aliasing rule を前提とした最適化なんて、速度に如実に効いてくるけど人々の「余計なことをしない場合はこうなる」という期待を裏切る典型例よね
あとは「未定義動作を踏む実行パスには到達しないはず」という原始的な到達性解析をもとにした分岐の除去とかも結構効いてくるはず
最近Cコンパイラ書きたいなという気持ちが（何度目かの諦めを経て）あり、これまでの単にコンパイラを使うだけの立場では「UBは何が起きてもおかしくないから避けて書くべきだよな」だったけど、コンパイラを書く側になってみると「何が起きてもおかしくないと警告されているからといって《俺が何でもやっていい》わけじゃなくないか？」という気持ちが生まれたという状況。
何かしらのコンパイラを書いてみたい気持ちはあり、言語の素朴さと実用性のバランスをとると当然 C は候補に上がってくる。
で、当然憎き UB をどうするか考えることになるわけだけど、そもそも実用的に/原理的に検出が困難な場合も多い UB をどうするか考えるとき、警告出せそうにないなら「最も素朴な動作」にしようかというのは当然考える。
なんだけど、これって「言語として与えられていない保証を追加で与え、本来 portable でないプログラムをあたかもそうであるかのように見せるコンパイラ本位な振舞なのではないか」と思うのよ
The Harmful Consequences of the Robustness Principle
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-05.html
これのことを思い出したりもするけど、「未定義動作がそれらしく動くコンパイラ」が増えることは、つまり「本来は保証されていないのにそう動くことへの人々の期待を強める (さらには気付く機会も奪う)」ということだと思っていて、これはエコシステム全体を長期的に見たときの害がかなり大きいし、将来の規格策定の邪魔にもなると思う
たとえば hash map で実行ごとに順番が安定すると必ずそれを期待する人が出てくるからプロセスや hash map のインスタンスごとに乱数を使わせて順番をランダムにするみたいな話もそうなんだけど、むしろ「期待してはいけない挙動は積極的に壊れる」ことこそ親切なのではないかなと。で、そのうえ高速化に使えるなら一石二鳥よね
そしてそもそも検査でどうにかなりそうなものは近年 sanitizer で吸収していく流れなので (UBSan, TSan, ASan, etc.)、そういう意味でも「“明らかな” 未定義動作に気付けないのは開発者の怠慢」「“明らかでない” 未定義動作はそもそも気付くことが困難なのだからできるだけいろいろな場面でその存在を認識できる方が良い」という二方面作戦で行くのは悪くない話かもしれないと。
積極的に壊す（または反例を示す）のは最適化パス以外の、たとえばsanitizerなどの仕事かなと私は思う。遅くなる方向でコードを壊すのは最適化パスでやりたいことではないわけだし。
これは程度の問題かなという気がして、既存の sanitizer で数倍とかの規模で遅くなるやつはかなり困るから sanitizer として分けてほしいし、 sanitizer はそれなりに false positive か false negative が少ないことを要求したいけど、 UB を利用した最適化がコストも精度もそこまででないなら普通にオプションとしてありかなと (それを “最適化” と呼ぶかはまたちょっと話が変わってくるけど)
「UB を積極的に壊さないオプション」もまあありえるけど (-fno-strict-aliasing みたいに)、それって結局効果はコンパイラ依存だしエコシステムがそれを前提にしていくと「規格に準拠したコンパイラなのに意図したバイナリを出せない」みたいなのが増えていくわけで、いや……ちょっとそれはなぁ……
プログラマはそんなに馬鹿じゃないから自制できるだろというのはもう既に歴史に否定されていると思っていて、これからはそういう「エコシステムを腐らせないための “税金”」を徴収して健全性を保つような仕組みも視野に入れるべきなんじゃないかなぁ、というのが最近の考えです
まあ「未定義動作が出現する」がどういう形であるべきかは議論の余地があるし (何であれ壊れはしているので random value が読まれるだけでも致命傷になりうるけど)、そこでせっかくだから最適化に使おうというのはそんなに理不尽な話ではないと思っている。
まあ未定義動作をアグレッシブに最適化に使おうとする人々がそういう強い思想や動機をもってやっているかは知らないけど……
まあ個人的には UB の扱いよりも浮動小数点数の扱いの方がヤバいだろという感想はあります (しかもコンパイラではどうにかしようにも限度があるあたりもつらい)
-O2 と -O3 が分かれているのはコンパイラ開発者の良識のあらわれだと思っている
Optimize Options (Using the GNU Compiler Collection (GCC))
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
-Ofast の
> Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs.
の勢いがヤバくて笑ってしまう
メジャーなコンパイラがUBを積極的に最適化パスで使うのは端的に言えば「ベンチマークテストで競合に勝つため」だと思う。さっき言及したけど、フェイルファストという意味では最適化パスでやらない方がそれに専念できるので。
最適化パスと UB 伝播パス (?) のステージを分けてもいいとは思うけど、結局それは意識低いユーザによる未定義動作の “乱用” を促進するだけなのと、内部実装的には (アクセスできる解析情報的には) 似たようなものになりそうな気がしていて、だったら分ける旨味そんなになさそうという気がしている
結局 UB を乱用/悪用 (abuse) するのがユーザになるのかコンパイラになるのかという話になりそうで、そもそも「ユーザがコントロールできるべき領域」は明確に規格で決まっているわけなのだから、コンパイラが UB を滅茶苦茶にしたからといって「ユーザに与えるべきコントロールがコンパイラに奪われている」とは言えないのではないか、と思います
あるいは特定の従来 UB だった挙動をユーザが制御できるべきなら、規格でそう定めるようにするのが正道だと思っている
まあそれはそれとして、ガードレールが欲しいのはマジだし sanitizer よりもう少し悪影響が軽いような何かしらの仕組みがあればそれが良いというのは確かにそう
一方で、ナイーブなコンパイラならUBに関するプログラマーの誤った仮定を守ってくれるとも限らなくて、-fwrapvのように積極的にプログラマーを守るという方向もある。ただ、私の立場は「常に-fwrapvしろ」とかではなくて、あくまでも最適化パスで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>)。
「UB で高速化するくらいならクラッシュしろ」についてはまあ基本的に大賛成ということになります、ユーザが気付ける機会が増えて悪影響も (狂ったまま実行を続けるのに比べれば) ほぼ最小になるので。
たとえば到達不可能なはずのコードパスで UD2 命令に飛ばしたりするのはそういう “良い” コンパイルですよね (これも広義には最適化と呼んでいることはあるのかな)
でもクラッシュできず実行を続けてしまうならもう高速化に使おうが “素朴に” 放置しようが大差なくないか？
だったら本当に「コンパイラからは検証できないが、未定義動作を踏まないようユーザが注意深くコーディングした結果のソースコード」なのかもしれないし、それを最適化に使おうというのはまったくもって「最適化」として正当であると思う。そのうえで性能の評価はすべきだろうけど。
未定義動作だからといって必ず踏む可能性があるとは限らないわけで。
ところで、それ自身が大規模なC++の実アプリケーションであるGCCやClangにどれくらいUBが埋まっているのかというのはかなり気になる。
ICE は氷山の一角だろうけど (no pun intended)、結構あるのだろうな
私としては素直には受け入れ難いけど、たとえば「プログラムに与える入力は、必ず、絶対に、注意深く、事前定義されたいくらかの候補や事前検証された形式のものしか使わないので、プログラム側で実行時に意図せぬ入力を考慮する必要はない」みたいなこともあるかもしれない。
その場合は明らかに未定義動作が心配されるコードであっても未定義動作パスは (運用上) 絶対に踏まないので無駄なチェックは積極的に省きたということになる。
職場でやられたら絶対反対するけど！！！
プログラム単位だとマジかよとなるけど、プログラム内の小さなモジュール単位だとこういうことは当たり前のようにやっているので……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
