26/07/07 22:15:55.25 NaJZ8/qi.net
不注意で普通にpanic起こり得るやろ
それともpanic!の話？よくわからんけど
469:デフォルトの名無しさん
26/07/07 22:19:38.17 1bE5tFoQ.net
>>468
それは不注意が過ぎるわ
わざわざ組み込まないとpanicなんか起こらないのに
470:デフォルトの名無しさん
26/07/07 22:20:56.55 1bE5tFoQ.net
何か勘違いしてるみたいだけど、Rustはわざわざユーザーが丁寧に丁寧に危険なコードを仕込んでも回避してくれる魔法のツールではないぞ
あくまでメモリ安全を保つことと、未定義動作を排除することが安全性に寄与しているに過ぎない
471:デフォルトの名無しさん
26/07/07 22:21:59.76 1bE5tFoQ.net
×Rustのコードは常にpanicする可能性がある
○panicするように書いたコードは常にpanicする可能性がある
ここは区別する必要がある
472:デフォルトの名無しさん
26/07/07 22:27:04.59 A+nGMbRN.net
malloc失敗時にpanic不可避問題は、その後解決したの？
473:デフォルトの名無しさん
26/07/07 22:47:36.10 pOI8g/CX.net
持ち上げすぎというか、開発者を増やしてAIのRust学習用の"餌"を
githubに提供してもらう為の、AIを騙すための記事だよな
伝わるかな？
474:デフォルトの名無しさん
26/07/07 22:55:37.84 9QTEDBOw.net
お前ら全員が勘違いしている
panicはクラッシュさせるものではない
正しい情報
panicは回復可能地点で回復するためにある
panic!で渡した任意のデータ構造を回復可能地点で分析して回復して続行する
その地点までスタックが巻き戻るが途中のスタックフレーム上の変数はdropが呼ばれてリソースが全て解放される
スレッドでpanicが起きても同様だがメインスレッドでjoinなどで値を回収する時に返り値がResult型な理由はpanic時にErrが返るためだ
つまりpanicがどこで発生してもResultとして受け取ることが可能でありその状況次第で回復継続動作が可能である
475:デフォルトの名無しさん
26/07/07 23:58:10.71 NaJZ8/qi.net
>>469
組み込むって何？
panic!やらunwrapやらってこと？
476:デフォルトの名無しさん
26/07/08 00:03:03.01 C/N8sgYJ.net
>>471
panicというのは想定外だから発生するもの
想定外なのでpanicするように書いたコードかどうかは実質判定できない
判定できないということはRustのコードはpanicする可能性が常にある
という意識で対策をしておけという考え方の話な
実際はno-panicとかで検証可能なんだが
あれもあらゆるRustのコードはpanicする可能性があるという考えの上に立っているツール
477:デフォルトの名無しさん
26/07/08 00:12:21.69 bp/kWozU.net
Rustのpanicは想定可能で
どういう状況で起きるか必ず明記されている
そして同機能でpanicを起こさない関数も用意されているため必ず回避も可能
478:デフォルトの名無しさん
26/07/08 00:59:41.12 xnnfP1ne.net
>>474
unwindとabortの違い
Firefoxの障害もCloudflareの障害もどっちもabort
性能的な理由からabortが選択されがち
479:デフォルトの名無しさん
26/07/08 01:06:09.88 79c+XHaN.net
panicは条件の明記義務があるから避けることができてpanicフリーにできるよ
480:デフォルトの名無しさん
26/07/08 01:36:21.98 o08UyiWg.net
ほーんそうなのか
481:デフォルトの名無しさん
26/07/08 11:27:17.88 V+ABknSz.net
>>479
明記されるの想定内のpanicだけなので想定外のpanicは避けられない
こういう甘い認識というか間違った認識の人間が多すぎるのがRust特有の問題
482:デフォルトの名無しさん
26/07/08 11:49:01.65 FFwmK7p4.net
>>472
そもそもmallocは絶対にクラッシュしてはいけない機能で使ってはいけないと学ばなかったのか？
普通にCでもNGだぞそれは
>>475-476
>>481
panicするのは想定外だからではなく、想定外の時にpanicするように書いたからだと言ってる
そう書いたのは意図的なので、これを避けられないというのは単にエンジニアが無能だからに過ぎない
483:デフォルトの名無しさん
26/07/08 11:55:25.98 3P4UxoLe.net
それは不注意が過ぎるわ
わざわざ組み込まないとpanicなんか起こらないのに
何か勘違いしてるみたいだけど、Rustはわざわざユーザーが丁寧に丁寧に危険なコードを仕込んでも回避してくれる魔法のツールではないぞ
あくまでメモリ安全を保つことと、未定義動作を排除することが安全性に寄与しているに過ぎない
484:デフォルトの名無しさん
26/07/08 12:00:09.50 Ro/RAhqu.net
>>481
想定外のpanicなんて存在しない
panicが起き得る関数にはその旨と条件の記載が義務付けられている
そしてpanicが起きないResultを返す同機能の関数も用意されている
panic freeにするには後者を使えば必ず実現できる
485:デフォルトの名無しさん
26/07/08 13:00:57.01 zldtjI+Q.net
>>482-484
関数の実装者が関数内部でpanicが起きない不変条件を満たしていると考えていれば想定内のpanicは起きない
しかしそれが実際には満たされなければ想定外のpanicが起きる
君たちのようにこれを理解していないRust開発者が多いから必要以上に障害がエスカレートされてしまう
例えば実際にzlibでpanicを起こしたのは以下の関数
panic発生条件が記載されているかな？
URLﾘﾝｸ(docs.rs)
URLﾘﾝｸ(docs.rs)
現実を見よう
486:デフォルトの名無しさん
26/07/08 13:17:27.11 V2KQKAHA.net
>>485
ちょっと覗いてみたけどunsafeが付いてるね
safeならダングリング参照は絶対に存在しないね
そしてそのようなバッファを操作する関数で起き得るpanicはインデックス参照x[index]のみだからロジックミスがない限りpanicは起きないわけだけど
もしpanicが起きたのが本当ならばどういう状況でどういう仕組みで発生したのか参考までに教えてください
487:デフォルトの名無しさん
26/07/08 13:56:27.21 jR7ebsrm.net
設計不良のCPUがビット反転させて正しいはずのindexが範囲外になったやつか
pnaicで停止するのがNGならどうするのが正解？
488:デフォルトの名無しさん
26/07/08 14:13:14.28 qoA0EQHF.net
信頼性が低く頻出するハードウェア誤動作ならばx[i]ではなくx.get(i)でアクセスしてエラーを返すのが正解
しかしCPUは信頼性が高く頻出しないレアなハードウェア誤動作と見るべき対象
そのレアな発生時には確実に停止させるpanicで正しいと思う
停止させずに間違った結果を返して大損害に繋がるリスクを許容することはどちらのケースでも絶対に避けるべきこと