Rust part23

1 名前：デフォルトの名無しさん [2024/02/23(金) 17:37:52.13 ID:CheDQupm.net] 公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust 公式ドキュメント https://www.rust-lang.org/learn Web上の実行環境 https://play.rust-lang.org ※Rustを学びたい人はまず最初に公式のThe Bookを読むこと https://doc.rust-lang.org/book/ ※Rustを学ぶ際に犯しがちな12の過ち https://dystroy.org/blog/how-not-to-learn-rust ※Rustのasyncについて知りたければ「async-book」は必読 https://rust-lang.github.io/async-book/ ※次スレは原則>>980が立てること 前スレ Rust part22 https://mevius.5ch.net/test/read.cgi/tech/1705760500/ ﾜｯﾁｮｲスレ プログラミング言語 Rust 4【ﾜｯﾁｮｲ】 https://mevius.2ch.net/test/read.cgi/tech/1514107621/ 321 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 10:43:30.71 ID:5CgUbd5q.net] だが読むより書くほうが優れているという前提から 原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる 322 名前：デフォルトの名無しさん [2024/03/15(金) 11:53:24.75 ID:94MXVgRN.net] 春だなぁw 323 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 18:26:51.96 ID:5N0PtL1J.net] ai bot 324 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 20:40:42.93 ID:W8LQpOAr.net] >>315 辛辣で草 そういう似非技術者系おじいちゃんおちょくると 怒って自分が唯一知ってる知識振り回してくるから面白いぞ 325 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 21:07:06.30 ID:8+Y0uCh5.net] Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい ここはRust専用スレ 326 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 21:26:31.60 ID:PnOJWcC7.net] コーディングが出来なくなると人生はつらいと思うけどな… 327 名前：デフォルトの名無しさん mailto:sage [2024/03/15(金) 21:36:49.30 ID:3GkeGGWK.net] できなくなるんじゃなくて 元々できてないんよね>>314みたいな人は というより単に職業マじゃないのかもな 趣味でプログラム触ったことあるパソコン少年的な 328 名前：デフォルトの名無しさん mailto:sage [2024/03/16(土) 00:23:32.44 ID:/iia2JvS.net] 人はいつか何もできなくなって死んでいくんだよな つまらないね 329 名前：デフォルトの名無しさん mailto:sage [2024/03/16(土) 08:54:22.01 ID:aeW ] [ここ壊れてます] 330 名前：u0EgX.net mailto: 肉屋がレッドオーシャンになれば豚はブルーだからこれでいい [] [ここ壊れてます] 331 名前：デフォルトの名無しさん [2024/03/17(日) 19:33:58.02 ID:1VtyMVPz.net] Rust書けるやつ集めるの大変すぎ 332 名前：デフォルトの名無しさん mailto:sage [2024/03/17(日) 22:06:35.75 ID:BMZldfUE.net] Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな ただしまともなプログラマーしか使い　　こなせない 333 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 09:59:50.17 ID:ySp1yGcK.net] むしろ変なやつしか使ってない感じだけど… 334 名前：デフォルトの名無しさん [2024/03/18(月) 10:20:48.83 ID:JObkxwF0.net] しょーもないこだわり持ってるやつしか使ってない 335 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 13:49:12.09 ID:lCCxn1Q7.net] 今後の仕事考えたらRustだね 336 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 14:26:36.03 ID:1+ObkRXf.net] メモリ安全性ってなんなの？ 337 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 14:49:59.91 ID:RRSB5dTk.net] 無効なアドレスを参照しない 運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる 無効なアドレスを更新しない 運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる メモリリークは割とどうでもいい 338 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:00:45.39 ID:ZJ4hMg34.net] >>330 メモリ安全性のうち特に重要な一つがメモリ競合の安全性 まだ使っている値を意図せずに書き換えてしまい矛盾してしまう プログラミングで起こるバグの代表的な一つ Rustではこれを防ぐことができる 339 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:02:35.53 ID:1+ObkRXf.net] >>331 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました…… 340 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:07:28.37 ID:1+ObkRXf.net] >>332 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね… 341 名前：デフォルトの名無しさん [2024/03/18(月) 18:35:36.34 ID:utey1W8X.net] セルフコントならもう少し面白いやつを頼む 342 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 01:19:02.24 ID:6E76csi8.net] WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。 ttps://www.security-next.com/154875 343 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 05:37:59.51 ID:wTR4SIFK.net] デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。 2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。 パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。 344 名前：デフォルトの名無しさん [2024/03/20(水) 12:50:32.15 ID:/slJg93x.net] >>336 そういうのRust関係ないからわざわざここに書かなくてもいいよ 345 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 13:00:27.22 ID:3fTCja3E.net] 関係無いわけないでしょｗ rustで書かれてたら安全なんじゃなかったん？ｗ 346 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 13:48:07.28 ID:i9d3tzeg.net] ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ 347 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 14:22:40.25 ID:HLjoI2yW.net] これは「メモリ安全」の外の話？中の話？ 348 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 16:11:18.74 ID:sC/F3tDJ.net] unsafe使用箇所だからメモリ安全の外だろうな インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない 349 名前：デフォルトの名無しさん mailto:sage釣 [2024/03/20(水) 16:33:56.60 ID:pz7pPV/0.net] jsonの方も？ 350 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 17:50:49.65 ID:w9jt/Hdz.net] コード見てみたが言語関係なくダメな書き方の見本ってだけだな ttps://github.com/wasmi-labs/wasmi/commit/f7b3200e9f3dc9e2cbca966cb255c228453c792f ttps://github.com/wasmi-labs/wasmi/blob/v0.31.0/crates/wasmi/src/engine/stack/values/mod.rs#L158-L163 修正コードは毎回境界チェックしてるのと同じ extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない 351 名前：デフォルトの名無しさん [2024/03/20(水) 18:13:46.74 ID:ASk8Mk2n.net] extendという名前も実体と違ってバクの素 352 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 18:19:15.64 ID:sC/F3tDJ.net] 修正コードはhotfixでしょ masterブランチの方は結構手が入ってると思う 353 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 18:27:22.61 ID:ihbrcjwp.net] その知識やスキルを活かして出世して欲しい 354 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 20:04:41.25 ID:TrbgWl+Z.net] ダメな書き方でもコンパイルが通れば安全なはずなのではｗ 355 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 20:32:22.01 ID:sC/F3tDJ.net] んなこたない ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる 356 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 01:05:26.83 ID:CBfowBe/.net] 直接の原因はunsafeなメソッドをsafeメソッドにしたこと unsafeのsafe wrapperの質は大事 今のコードもunsafeの使い方が怪しくて信頼できない fn get_release_unchecked_mut(&mut self, index: usize) -> &mut UntypedValue { debug_assert!(index < self.capacity()); // Safety: This is safe since all wasmi bytecode has been validated // during translation and therefore cannot result in out of // bounds accesses. unsafe { self.entries.get_unchecked_mut(index) } } 357 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 01:39:19.40 ID:t5wrhqh7.net] >>350 俺んとこもそのコードはよく書くけれど 今回の敗因は引数のindexが生のusizeであること そこをusize直接ではなくそのラッピングの専用型にする そしてその専用型が動く範囲が必ず範囲内であることを保証する形で get_uncheckefのunsafeを使う関数をsafeに仕上げる 358 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:05:54.93 ID:QWnK+qvS.net] unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？ 359 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:57:12.18 ID:7RDAu5V5.net] 全然そういう事 Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい 360 名前：デフォルトの名無しさん [2024/03/21(木) 20:09:58.67 ID:gM/gTjZ5.net] >>353 それ言うなら 無闇に「ヤバい」を使うぐらいヤバい じゃね 361 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:26:53.11 ID:1l7zk65j.net] 俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな ガンガンunsafe使ってこーぜ！！ 362 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:28:39.30 ID:7RDAu5V5.net] >>354 それだと単なる自己言及だから352に対する答えとして不十分では 363 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:45:04.06 ID:t5wrhqh7.net] 少なくとも>>350のindex: usizeは 何らかラッピング { index: usize }と別型にすべきところ まず範囲外のusizeでうっかり使っても型エラーにできる そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる 364 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:05:14.02 ID:7RDAu5V5.net] NonZeroとかNonNullみたいな固定条件ならいいけど 範囲みたいな可変条件だと型だけじゃ厳しいでしょ 別の条件で作られた同じ型の値を使われるかもしれないし ライフタイム 365 名前：で条件と関連付けるのも限界がある 結局テストパターン増やしてdebug_assert踏むしかない [] [ここ壊れてます] 366 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:44:37.76 ID:t5wrhqh7.net] >>358 もちろん二段階 まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける 次にコーディングやレビューやメンテでその専用型の動きに注視できる 367 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:18:44.86 ID:cOunjWn7.net] unsafeをsafeでないのにsafeにしておいて ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです 368 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:27:42.27 ID:WuGieKPN.net] 結局プログラマが色々意識してコーディングしないと安全にはならないのね こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど 369 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:07:15.31 ID:7RDAu5V5.net] unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる 実際は安全の為でもpanicで止まると困るから色々注意しないといけないし unsafeで余計なチェック省いたり黒魔術使ったりもする Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない 370 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:12:07.53 ID:v/mpoJJ8.net] >>361 unsafeを使わなれば自動的に安全が保証される unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない 371 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:22:25.34 ID:WuGieKPN.net] いつもの人がきたｗ 結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど 372 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:58:23.31 ID:z414Bs3I.net] > Rustであれば安全と思ってる人が多そう いや一応言っとくけど多くはないよ流石にｗ 一部の人が連呼してるだけ ほかの人はもっと現実的だろな 373 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:21.08 ID:t5wrhqh7.net] 原則はunsafeを使うな！ これだけだ 理解できていてunsafeを使う場合も とにかく閉じ込めろ！ 専用のクレートを作れ 専用のモジュールを作れ 専用の型を作れ 374 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:51.15 ID:XJ9dJAV6.net] unsafe使わなければ安全 375 名前：デフォルトの名無しさん [2024/03/22(金) 09:16:28.77 ID:IQ7X1X+j.net] まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。 それは意識して気をつけた方がいい。 376 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 10:19:34.77 ID:avPqaarP.net] ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。 チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。 そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ…… 普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。 377 名前：デフォルトの名無しさん [2024/03/22(金) 11:58:26.79 ID:7Rs7masV.net] >>358 0〜127の範囲のみを取りうるようなEnumなら作れる wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本 それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない >>359のやり方はそれができてないように感じる 378 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 12:34:01.41 ID:TbCMvv+/.net] 実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい そうすればその型に対して常に安全にget_uncheckedを使える 379 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:04:42.65 ID:ZrfX32kv.net] Rustは失敗言語 380 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:10:55.04 ID:ceR9yHkM.net] 今回の件でRustの安全性が確実になったのが興味深いよな アンチが必死に探してきた問題も>>350でunsafe利用だった 381 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 16:00:31.63 ID:JqYXTM4B.net] >>371 「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど 実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ unsafeにする意味がない 382 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 17:14:19.13 ID:vuLWDWdh.net] >>374 実行時コストをかけないためにget_uncheckedを使うのが一般的 その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法) 383 名前：デフォルトの名無しさん [2024/03/22(金) 19:27:28.32 ID:G6tKD1fj.net] Adaなら特定の範囲の型作れるみたいよ 384 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 20:07:18.97 ID:vuLWDWdh.net] 今回は範囲が固定ではなく変わり得る 385 名前：デフォルトの名無しさん mailto:sage [2024/03/23(土) 23:29:45.64 ID:eeq00BcS.net] 誰にでもunsafeが使えてしまうのが問題なのでは？ 原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。 386 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 00:34:36.37 ID:iaJ2USO3.net] Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。 まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。 387 名前：デフォルトの名無しさん [2024/03/24(日) 10:55:06.56 ID:UXqlkypu.net] >>375 「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350の引数のindexをその型に変えたところでsafeにしたらダメだよ 388 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 11:08:34.82 ID:BHU0SFkf.net] なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？ 389 名前：デフォルトの名無しさん [2024/03/24(日) 11:48:11.45 ID:uu8/yG2s.net] indexの境界チェックが律速になるようなコード書いてみてえな 390 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 20:37:14.59 ID:YsO86RjG.net] >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー　配列もその範囲指定で自由に作成できる。 391 名前：デフォルトの名無しさん [2024/03/24(日) 20:45:58.90 ID:Rrl8qRWO.net] >>383 定数じゃなければ結局実行時にチェックするってことだよね 392 名前：デフォルトの名無しさん [2024/03/25(月) 01:12:47.74 ID:yMlw6u5B.net] >>384 新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。 393 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 07:21:41.59 ID:CNajD+3j.net] >>384 何十年も前なのですまそ array(-2)とかarray(6)をアクセスしたら例外発生　array(-1)はOK type Month is range 1..12 type Month_Array is array(Month) of Integer; ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12); for m in ma'first..ma'last loop // カウンタは1から12 ma(m) = m; end loop; 394 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 14:37:28.19 ID:x/lXcXel.net] 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね 395 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 16:23:44.40 ID:9GDk/VLW.net] How much does Rust's bounds checking actually cost? https://blog.readyset.io/bounds-checks/ 396 名前：デフォルトの名無しさん [2024/03/25(月) 17:27:16.04 ID:MT/jL+52.net] こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。 問題は浮動小数の取り扱いだっての。 397 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 21:23:48.62 ID:x/lXcXel.net] unsafeは可能な限り避けるべきで safe Rustでの改善をまずすべき その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える 現実にはsafe Rustでの改善ができてないことが多い 例えばよく見かける例としては iが動いていくのにa[i]でアクセスしてしまう これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern 参照(ポインタ)化することで範囲checkを1回に減らせる 398 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 15:06:55.14 ID:g9hYSxJr.net] unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事 399 名前：デフォルトの名無しさん [2024/03/27(水) 15:29:03.70 ID:pFQTMi8v.net] 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」 が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので 400 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:02:47.08 ID:BwG0n/Az.net] unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。 unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？ 401 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:59:36.71 ID:LwoOYerE.net] >>393 そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。 402 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:05:39.09 ID:6Vj8sISV.net] >>392 センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ 今はそれが全然できてないから>>350のような基本的なミスを犯すやつが後を絶たない 403 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:08:09.55 ID:6japDZ8y.net] windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。 404 名前：デフォルトの名無しさん [2024/03/27(水) 18:09:17.85 ID:345wycOn.net] >>395 ～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。 405 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 18:27:03.05 ID:3NgGdhlw.net] >>397 問題点の指摘や解決策の提案と 問題解決のために実際に誰が動くのかという 2つの異なるものを混同したらだめだよ マネジメント101 406 名前：デフォルトの名無しさん [2024/03/27(水) 18:54:43.86 ID:nHNmKGrp.net] その素晴らしい提案がなぜされていないのか考えよう そしてなぜ自分は実行から逃げているのか考えよう 407 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 20:42:45.86 ID:deTzlgug.net] >>394 Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。 408 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:06:58.89 ID:LwoOYerE.net] unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。 危険な操作も含まれるけど危険な部分を分けれてるわけではない。 もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。 409 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21 ] [ここ壊れてます] 410 名前：:18:47.87 ID:deTzlgug.net mailto: >>401 安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。 デフォルト禁止でもいいくらい。 [] [ここ壊れてます] 411 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:31:01.25 ID:LwoOYerE.net] >>402 だからそうしたいならそうすりゃいいって話をしてる。 あなたが裁量権をもつプロジェクトでは。 私が反論してるのは「そのためのものだ」という部分に対して。 412 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:44:58.62 ID:deTzlgug.net] >>403 Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。 unsafeはデフォルト禁止でいいよ。 413 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:49:49.48 ID:Fy0R0co2.net] 理想をいえばunsafeなんて無いならサイコーだったんだろうね rust陣営もしゃあなしでunsafe導入したんやろうし unsafeなしですべてがセーフで効率的だったら そりゃあrustは本当に素晴らしい文句なしの言語だったやろな 414 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:08:33.46 ID:toZsv7uT.net] 生ポインタすなわちCPUによるメモリアクセスはunsafe そこが出発点 unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる それがsafe Rustの基本原理 つまりunsafeに行き着くためunsafe無しでは何もできない これが真理 一方で unsafeを閉じ込めたライブラリ利用可を前提にすれば unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実 415 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:24:02.18 ID:cgbLYCC5.net] >>406 だったらデフォルトunsafe禁止で良い。 どこでもunsafe okはやっぱりチグハグ。 416 名前：デフォルトの名無しさん [2024/03/27(水) 22:52:47.09 ID:qNf/D02g.net] そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？ 417 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:57:38.14 ID:LwoOYerE.net] >>404 「そうであって欲しいと自分は思っている」なら別にいいよ。 ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。 418 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 23:02:28.02 ID:toZsv7uT.net] #![forbid(unsafe_code)] を宣言すればいい もちろんすべてはunsafeへ行き着くため unsafeを禁止できるのは自分のコード部分だけ 419 名前：デフォルトの名無しさん [2024/03/27(水) 23:55:45.93 ID:pFQTMi8v.net] unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな 平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する 420 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 07:44:09.91 ID:OabXy/xk.net] >>409 公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。 >>411 拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？ 421 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:15:17.48 ID:wHq/ItvK.net] rustもいろいろ問題を抱えてるんだね プログラマの習熟が必要だっていうなら流行らないだろう メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし 新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef