Rust part23

**デフォルトの名無しさん** · 2024/02/23(金) 17:37:52.13

公式
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/

**デフォルトの名無しさん** · 2024/03/12(火) 01:05:51.45

常に論点ずらし
何の生産性もない

**デフォルトの名無しさん** · 2024/03/12(火) 01:42:25.91

いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン
今回のHashMapの件で例えると
もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない！」と叩く
もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い！」と叩く
どちらになっていても叩くことが目的のキチガイ

**デフォルトの名無しさん** · 2024/03/12(火) 09:25:30.86

「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが
「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる

**デフォルトの名無しさん** · 2024/03/12(火) 15:42:43.44

『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い

**デフォルトの名無しさん** · 2024/03/12(火) 16:02:50.20

ほんとどうでもいいな
自転車置き場というより豚小屋の議論

**デフォルトの名無しさん** · 2024/03/12(火) 16:28:46.76

プログラムしかしない人はこういうことしか考えることがないんよ

**デフォルトの名無しさん** · 2024/03/12(火) 17:33:47.15

知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。
安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。

**デフォルトの名無しさん** · 2024/03/12(火) 18:00:43.49

デフォルトいらんが
ハッシュも自分で選べんガイジがハッシュマップ使うな

**デフォルトの名無しさん** · 2024/03/12(火) 18:49:06.95

>>279
わかってなさそうなので再度書くけど
ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね

**デフォルトの名無しさん** · 2024/03/12(火) 18:51:51.27

弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。

**デフォルトの名無しさん** · 2024/03/12(火) 19:50:55.41

攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。
そして攻撃されてから対処するのでは遅いかもしれない。
パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。

**デフォルトの名無しさん** · 2024/03/12(火) 19:59:05.75

>>283
同意

**デフォルトの名無しさん** · 2024/03/12(火) 20:00:13.63

RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない
もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている
そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる

**デフォルトの名無しさん** · 2024/03/12(火) 20:49:08.64

Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ

**デフォルトの名無しさん** · 2024/03/12(火) 20:49:29.65

他の言語たちがRustを参考に同じように後追いしているのね

＞Pythonの文字列やバイト列に対するハッシュアルゴリズムは、HashDoS対策としてPython 3.4から SipHash24が使われていました。
＞その後、ラウンド数を減らしたSipHash13でも十分に安全だとして2015年にRustが、2016年にRubyが、SipHash24からSipHash13への切り替えを行いました。
＞Rust や Ruby からは数年遅れましたが、Pythonもデフォルトの文字列ハッシュアルゴリズムがSipHash13に切り替わりました。

**デフォルトの名無しさん** · 2024/03/12(火) 20:56:37.07

>>286
常にそれをされたら困るが
Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている

**デフォルトの名無しさん** · 2024/03/12(火) 22:08:56.94

>>274
人にキチガイと言う前に自分の脳を使って考えたら？

どちらになっても叩くことはないだろ
他の言語はデフォルトで速いハッシュを使ってるよ

**デフォルトの名無しさん** · 2024/03/12(火) 22:13:42.86

Python　Ruby　スクリプト系言語

**デフォルトの名無しさん** · 2024/03/12(火) 22:30:53.75

他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹

**デフォルトの名無しさん** · 2024/03/13(水) 01:06:52.67

他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう

**デフォルトの名無しさん** · 2024/03/13(水) 01:36:16.81

Swiftも同じSipHash13だよ

**デフォルトの名無しさん** · 2024/03/13(水) 06:48:44.81

>>292
じゃあRustの思想は？

**デフォルトの名無しさん** · 2024/03/13(水) 07:26:54.50

>>283
判断できない人まで言語側で救う必要性が分からない。

それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。

**デフォルトの名無しさん** · 2024/03/13(水) 08:05:27.17

必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは？

**デフォルトの名無しさん** · 2024/03/13(水) 11:53:59.71

安全と速度は両立するかそれともトレードオフか
トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね
有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない

**デフォルトの名無しさん** · 2024/03/13(水) 13:08:21.45

Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな
賢いならRustなんかやらない

**デフォルトの名無しさん** · 2024/03/13(水) 13:52:10.04

自由があればデフォルト設定を強制されないのは自明な事実
ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか
そもそも「所有している」というのはただの感想なのか客観的事実なのか

**デフォルトの名無しさん** · 2024/03/13(水) 15:08:41.44

アホ vs バカの不毛な争いが続くのは隔離スレにﾜｯﾁｮｲつけたやつの責任だからな

**デフォルトの名無しさん** · 2024/03/13(水) 17:12:52.60

本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。
5chでRust使ってるって言ってるやつらはそんなもの

**デフォルトの名無しさん** · 2024/03/13(水) 17:32:48.34

不毛の判断が早いなあ
後世の歴史家が判断するという定型文に縛られないから早いんだな

**デフォルトの名無しさん** · 2024/03/13(水) 17:40:34.76

安全と速度を両立させたのが
RustやPythonなどが採用しているSipHash13

**デフォルトの名無しさん** · 2024/03/13(水) 18:38:09.42

>>295
いや、unsafeは判断できる人が使うものだろ。

**デフォルトの名無しさん** · 2024/03/13(水) 21:22:31.53

>>300
分かってるんならﾜｯﾁｮｲ付きRustスレの盛り上げに協力してくれんかえ

**デフォルトの名無しさん** · 2024/03/13(水) 21:54:19.69

ワッチョイなんか盛り上がる訳ねえ
そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的

**デフォルトの名無しさん** · 2024/03/13(水) 22:31:42.96

高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話

**デフォルトの名無しさん** · 2024/03/13(水) 22:39:35.15

30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ

**デフォルトの名無しさん** · 2024/03/13(水) 22:42:16.17

出世出来ましたか？

**デフォルトの名無しさん** · 2024/03/13(水) 22:52:25.45

能力が低下してコーディングできないのとしないのでは大違い

**デフォルトの名無しさん** · 2024/03/14(木) 00:41:25.89

結局スクリプト言語で書かれた原作が必要か
他のジャンルでも原作なしのオリジナルは難しそうだろう

**デフォルトの名無しさん** · 2024/03/14(木) 12:30:54.13

Rustで書き直してパフォーマンスが上がったので注目浴びる！みたいなプロダクトはなんか白けるよな。
JSとかPythonの基盤ツールをRustで書き換えて激速！みたいなのはもう汎用言語としてのアイデンティティ捨てられててオワットル。

**デフォルトの名無しさん** · 2024/03/14(木) 12:34:38.63

日本みたいに、何とかするには人投入しよう！スキルどうでもいいからとにかく人集めて！なところじゃね～。

**デフォルトの名無しさん** · 2024/03/14(木) 13:45:31.80

おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。
歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて
速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。
(それは C++ で書かれてるんだけどね。)
商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。
リンカを作ってるところはこぞって高速化に努めた。
リンカ以外にもその機運が波及しているのが今。

で、高速化のキモはデータ構造であるというのが明瞭になったんだけど
メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。
Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。

**デフォルトの名無しさん** · 2024/03/15(金) 00:47:31.57

コードを書けない
プログラムできなくなるとこういうことしか書けなくなると言う見本

**デフォルトの名無しさん** · 2024/03/15(金) 10:43:30.71

だが読むより書くほうが優れているという前提から
原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる

**デフォルトの名無しさん** · 2024/03/15(金) 11:53:24.75

春だなぁw

**デフォルトの名無しさん** · 2024/03/15(金) 18:26:51.96

ai bot

**デフォルトの名無しさん** · 2024/03/15(金) 20:40:42.93

>>315
辛辣で草
そういう似非技術者系おじいちゃんおちょくると
怒って自分が唯一知ってる知識振り回してくるから面白いぞ

**デフォルトの名無しさん** · 2024/03/15(金) 21:07:06.30

Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい
ここはRust専用スレ

**デフォルトの名無しさん** · 2024/03/15(金) 21:26:31.60

コーディングが出来なくなると人生はつらいと思うけどな…

**デフォルトの名無しさん** · 2024/03/15(金) 21:36:49.30

できなくなるんじゃなくて
元々できてないんよね>>314みたいな人は
というより単に職業マじゃないのかもな
趣味でプログラム触ったことあるパソコン少年的な

**デフォルトの名無しさん** · 2024/03/16(土) 00:23:32.44

人はいつか何もできなくなって死んでいくんだよな
つまらないね

**デフォルトの名無しさん** · 2024/03/16(土) 08:54:22.01

肉屋がレッドオーシャンになれば豚はブルーだからこれでいい

**デフォルトの名無しさん** · 2024/03/17(日) 19:33:58.02

Rust書けるやつ集めるの大変すぎ

**デフォルトの名無しさん** · 2024/03/17(日) 22:06:35.75

Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな
ただしまともなプログラマーしか使い　　こなせない

**デフォルトの名無しさん** · 2024/03/18(月) 09:59:50.17

むしろ変なやつしか使ってない感じだけど…

**デフォルトの名無しさん** · 2024/03/18(月) 10:20:48.83

しょーもないこだわり持ってるやつしか使ってない

**デフォルトの名無しさん** · 2024/03/18(月) 13:49:12.09

今後の仕事考えたらRustだね

**デフォルトの名無しさん** · 2024/03/18(月) 14:26:36.03

メモリ安全性ってなんなの？

**デフォルトの名無しさん** · 2024/03/18(月) 14:49:59.91

無効なアドレスを参照しない
運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる

無効なアドレスを更新しない
運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる

メモリリークは割とどうでもいい

**デフォルトの名無しさん** · 2024/03/18(月) 15:00:45.39

>>330
メモリ安全性のうち特に重要な一つがメモリ競合の安全性
まだ使っている値を意図せずに書き換えてしまい矛盾してしまう
プログラミングで起こるバグの代表的な一つ
Rustではこれを防ぐことができる

**デフォルトの名無しさん** · 2024/03/18(月) 15:02:35.53

>>331
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました……

**デフォルトの名無しさん** · 2024/03/18(月) 15:07:28.37

>>332
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね…

**デフォルトの名無しさん** · 2024/03/18(月) 18:35:36.34

セルフコントならもう少し面白いやつを頼む

**デフォルトの名無しさん** · 2024/03/20(水) 01:19:02.24

WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。
ttps://www.security-next.com/154875

**デフォルトの名無しさん** · 2024/03/20(水) 05:37:59.51

デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。

2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。
パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。

**デフォルトの名無しさん** · 2024/03/20(水) 12:50:32.15

>>336
そういうのRust関係ないからわざわざここに書かなくてもいいよ

**デフォルトの名無しさん** · 2024/03/20(水) 13:00:27.22

関係無いわけないでしょｗ
rustで書かれてたら安全なんじゃなかったん？ｗ

**デフォルトの名無しさん** · 2024/03/20(水) 13:48:07.28

ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ

**デフォルトの名無しさん** · 2024/03/20(水) 14:22:40.25

これは「メモリ安全」の外の話？中の話？

**デフォルトの名無しさん** · 2024/03/20(水) 16:11:18.74

unsafe使用箇所だからメモリ安全の外だろうな
インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない

**デフォルトの名無しさん** · 2024/03/20(水) 16:33:56.60

jsonの方も？

**デフォルトの名無しさん** · 2024/03/20(水) 17:50:49.65

コード見てみたが言語関係なくダメな書き方の見本ってだけだな
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呼ばなければいけないとか反省の色が見られない

**デフォルトの名無しさん** · 2024/03/20(水) 18:13:46.74

extendという名前も実体と違ってバクの素

**デフォルトの名無しさん** · 2024/03/20(水) 18:19:15.64

修正コードはhotfixでしょ
masterブランチの方は結構手が入ってると思う

**デフォルトの名無しさん** · 2024/03/20(水) 18:27:22.61

その知識やスキルを活かして出世して欲しい

**デフォルトの名無しさん** · 2024/03/20(水) 20:04:41.25

ダメな書き方でもコンパイルが通れば安全なはずなのではｗ

**デフォルトの名無しさん** · 2024/03/20(水) 20:32:22.01

んなこたない
ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる

**デフォルトの名無しさん** · 2024/03/21(木) 01:05:26.83

直接の原因は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) }
}

**デフォルトの名無しさん** · 2024/03/21(木) 01:39:19.40

>>350
俺んとこもそのコードはよく書くけれど
今回の敗因は引数のindexが生のusizeであること
そこをusize直接ではなくそのラッピングの専用型にする
そしてその専用型が動く範囲が必ず範囲内であることを保証する形で
get_uncheckefのunsafeを使う関数をsafeに仕上げる

**デフォルトの名無しさん** · 2024/03/21(木) 19:05:54.93

unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？

**デフォルトの名無しさん** · 2024/03/21(木) 19:57:12.18

全然そういう事

Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい

**デフォルトの名無しさん** · 2024/03/21(木) 20:09:58.67

>>353
それ言うなら

無闇に「ヤバい」を使うぐらいヤバい

じゃね

**デフォルトの名無しさん** · 2024/03/21(木) 20:26:53.11

俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな
ガンガンunsafe使ってこーぜ！！

**デフォルトの名無しさん** · 2024/03/21(木) 20:28:39.30

>>354
それだと単なる自己言及だから352に対する答えとして不十分では

**デフォルトの名無しさん** · 2024/03/21(木) 20:45:04.06

少なくとも>>350のindex: usizeは
何らかラッピング { index: usize }と別型にすべきところ
まず範囲外のusizeでうっかり使っても型エラーにできる
そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる

**デフォルトの名無しさん** · 2024/03/21(木) 21:05:14.02

NonZeroとかNonNullみたいな固定条件ならいいけど
範囲みたいな可変条件だと型だけじゃ厳しいでしょ
別の条件で作られた同じ型の値を使われるかもしれないし
ライフタイムで条件と関連付けるのも限界がある

結局テストパターン増やしてdebug_assert踏むしかない

**デフォルトの名無しさん** · 2024/03/21(木) 21:44:37.76

>>358
もちろん二段階
まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける
次にコーディングやレビューやメンテでその専用型の動きに注視できる

**デフォルトの名無しさん** · 2024/03/21(木) 22:18:44.86

unsafeをsafeでないのにsafeにしておいて
ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです

**デフォルトの名無しさん** · 2024/03/21(木) 22:27:42.27

結局プログラマが色々意識してコーディングしないと安全にはならないのね
こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど

**デフォルトの名無しさん** · 2024/03/21(木) 23:07:15.31

unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる
実際は安全の為でもpanicで止まると困るから色々注意しないといけないし
unsafeで余計なチェック省いたり黒魔術使ったりもする
Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない

**デフォルトの名無しさん** · 2024/03/21(木) 23:12:07.53

>>361
unsafeを使わなれば自動的に安全が保証される
unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される
C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない

**デフォルトの名無しさん** · 2024/03/21(木) 23:22:25.34

いつもの人がきたｗ
結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ
Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど

**デフォルトの名無しさん** · 2024/03/21(木) 23:58:23.31

> Rustであれば安全と思ってる人が多そう

いや一応言っとくけど多くはないよ流石にｗ
一部の人が連呼してるだけ
ほかの人はもっと現実的だろな

**デフォルトの名無しさん** · 2024/03/21(木) 23:59:21.08

原則はunsafeを使うな！
これだけだ

理解できていてunsafeを使う場合も
とにかく閉じ込めろ！
専用のクレートを作れ
専用のモジュールを作れ
専用の型を作れ

**デフォルトの名無しさん** · 2024/03/21(木) 23:59:51.15

unsafe使わなければ安全

**デフォルトの名無しさん** · 2024/03/22(金) 09:16:28.77

まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。
それは意識して気をつけた方がいい。

**デフォルトの名無しさん** · 2024/03/22(金) 10:19:34.77

ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。
チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。
そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ……
普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。

**デフォルトの名無しさん** · 2024/03/22(金) 11:58:26.79

>>358
0～127の範囲のみを取りうるようなEnumなら作れる
wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど

サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本
それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない
>>359のやり方はそれができてないように感じる

**デフォルトの名無しさん** · 2024/03/22(金) 12:34:01.41

実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい
そうすればその型に対して常に安全にget_uncheckedを使える

**デフォルトの名無しさん** · 2024/03/22(金) 14:04:42.65

Rustは失敗言語