Rust part23 - 暇つぶし2ch

Rust part23 ..

241:デフォルトの名無しさん
24/03/11 22:17:15.26 1Ss4PFRT.net
ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる
やはりエコシステムやそこにある資産も含めての言語の評価だろう
それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる

242:デフォルトの名無しさん
24/03/11 22:22:30.50 2hCRIQro.net
>>241
C++だけでなくスクリプト言語であろうがすべて同じ
攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム

243:デフォルトの名無しさん
24/03/11 22:24:26.89 1Ss4PFRT.net
>>242
だからデフォルトなんかいらないんだよ
ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ

244:デフォルトの名無しさん
24/03/11 22:32:51.13 Zfy+Gd54.net
>>243
ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ
指定しないと使えない言語がもしあるとしてもレアじゃないですか？

245:デフォルトの名無しさん
24/03/11 22:38:01.21 1Ss4PFRT.net
>>244
それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう？
もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か

246:デフォルトの名無しさん
24/03/11 22:39:37.27 1Ss4PFRT.net
スクリプト言語だと速度は求められないという了解があるし

247:デフォルトの名無しさん
24/03/11 22:53:49.00 lga6QF6v.net
Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。
抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。

248:デフォルトの名無しさん
24/03/11 23:24:30.57 pnxYU4a7.net
あらゆる言語のあらゆるプログラムについて以下が成り立つ
【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない
【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切
そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切
Rustはこの適切な仕様となっている

249:デフォルトの名無しさん
24/03/11 23:26:28.61 srElBTmD.net
雨の降らない日に傘をさしてるのがRust

250:デフォルトの名無しさん
24/03/11 23:31:49.34 srElBTmD.net
外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust

251:デフォルトの名無しさん
24/03/11 23:39:22.87 H3LWtGm6.net
雨が降る日のためにいつでも傘をさしてるだけだろ…

252:デフォルトの名無しさん
24/03/11 23:47:29.47 1gRl0SR3.net
デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍
現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね
これはデフォルトが安全側に倒す形を取っていて正解と思う

253:デフォルトの名無しさん
24/03/11 23:47:55.83 eCeLdHKW.net
>>248
>【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
いやーそれはどうだろう？
ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね？
stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切

254:デフォルトの名無しさん
24/03/11 23:55:39.88 srElBTmD.net
hash自体は基本的にアホでも作れる
それが適切なのかどうかは不明

255:デフォルトの名無しさん
24/03/11 23:59:34.73 o1bdd8gz.net
Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど
すべての言語で用意されてるでしょ？
Rustは様々なハッシュ関数が標準ライブラリにないと言うけど
それが普通でしょ？
さらにRustの標準ライブラリはなるべく小さくする方針ね

256:デフォルトの名無しさん
24/03/12 00:02:16.02 YqCvYydB.net
>>255
ここまで読んでそういう解釈になってるなら理解する力が足りてない
重いハッシュ関数がデフォルトになってるのがどうなのかと言う話

257:デフォルトの名無しさん
24/03/12 00:06:26.32 hhdv8qp2.net
普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね
攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから
これより良い策があるの？

258:デフォルトの名無しさん
24/03/12 00:07:45.67 YqCvYydB.net
攻撃の可能性のある部分をチューンナップ

259:デフォルトの名無しさん
24/03/12 00:10:05.78 hhdv8qp2.net
>>258
バカなの？
それだとチューンアップする前が攻撃耐性ないじゃん

260:デフォルトの名無しさん
24/03/12 00:10:10.84 YqCvYydB.net
江戸時代士農工商の身分制度があって
雨の日だけ農民も下駄を履いてよかった

261:デフォルトの名無しさん
24/03/12 00:11:17.84 YqCvYydB.net
>>259
攻撃されないのに攻撃態勢をつける馬鹿

262:デフォルトの名無しさん
24/03/12 00:13:45.61 c71xUORt.net
みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ

263:デフォルトの名無しさん
24/03/12 00:15:25.47 YqCvYydB.net
IDコロコロ全肯定君
攻撃されるかもしれないのに攻撃の耐性をつけてない人に
対するフールプルーフのために一律全てのコードを遅くする
そもそもその人が設計ミスってるんだろう

264:デフォルトの名無しさん
24/03/12 00:15:58.38 ltF5NefG.net
SafeSlowHashMapみたいな名前にすれば良いのに

265:デフォルトの名無しさん
24/03/12 00:16:19.18 YqCvYydB.net
>>264
少なくともこれかな

266:デフォルトの名無しさん
24/03/12 00:27:26.16 hEPMmb8p.net
>>264 >>265
Rustを使ったことすらない人が文句を言ってるのか
RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する

267:デフォルトの名無しさん
24/03/12 00:32:47.44 YqCvYydB.net
>>266
HashMap::new()すらしたことないのかな？

268:デフォルトの名無しさん
24/03/12 00:33:47.12 P8rBcnCc.net
>>266
誰もそんな話してないやろ
これだから複クンは

269:デフォルトの名無しさん
24/03/12 00:35:30.45 YqCvYydB.net
こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ
いつもおかしなことを言ってる

270:デフォルトの名無しさん
24/03/12 00:36:58.41 4FnCuSr/.net
ripgrepとかuvとかの既に実用が始まってるRust製アプリでは
デフォルトのハッシュ関数使ってるの？

271:デフォルトの名無しさん
24/03/12 01:00:19.76 hEPMmb8p.net
>>267
やっぱりRustを使ったことないんだな
impl<K, V, S> HashMap<K, V, S>にfn new()は存在しないため
HashMap::<Key, Value, BuildHasherDefault<Hasher>>::default()のように使う

272:デフォルトの名無しさん
24/03/12 01:04:13.79 YqCvYydB.net
ほらこんな壊れたレスしかできないんだよ
脳が死んでる

273:デフォルトの名無しさん
24/03/12 01:05:51.45 YqCvYydB.net
常に論点ずらし
何の生産性もない

274:デフォルトの名無しさん
24/03/12 01:42:25.91 O5aTP+Ks.net
いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン
今回のHashMapの件で例えると
もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない！」と叩く
もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い！」と叩く
どちらになっていても叩くことが目的のキチガイ

275:デフォルトの名無しさん
24/03/12 09:25:30.86 2ftxmqwc.net
「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが
「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる

276:デフォルトの名無しさん
24/03/12 15:42:43.44 qP6Ph9LT.net
『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い

277:デフォルトの名無しさん
24/03/12 16:02:50.20 O51IPiXd.net
ほんとどうでもいいな
自転車置き場というより豚小屋の議論

278:デフォルトの名無しさん
24/03/12 16:28:46.76 6k71yQCv.net
プログラムしかしない人はこういうことしか考えることがないんよ

279:デフォルトの名無しさん
24/03/12 17:33:47.15 +dm3OZRm.net
知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。
安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。

280:デフォルトの名無しさん
24/03/12 18:00:43.49 ZUpYWJV7.net
デフォルトいらんが
ハッシュも自分で選べんガイジがハッシュマップ使うな

281:デフォルトの名無しさん
24/03/12 18:49:06.95 hIsWcrJS.net
>>279
わかってなさそうなので再度書くけど
ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね

282:デフォルトの名無しさん
24/03/12 18:51:51.27 wv71s4mp.net
弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。

283:デフォルトの名無しさん
24/03/12 19:50:55.41 WtXn1sYk.net
攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。
そして攻撃されてから対処するのでは遅いかもしれない。
パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。

284:デフォルトの名無しさん
24/03/12 19:59:05.75 1eKk9IjK.net
>>283
同意

285:デフォルトの名無しさん
24/03/12 20:00:13.63 uVbV4a/I.net
RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない
もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている
そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる

286:デフォルトの名無しさん
24/03/12 20:49:08.64 NxLZ8TT6.net
Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ

287:デフォルトの名無しさん
24/03/12 20:49:29.65 +yrdVDIt.net
他の言語たちがRustを参考に同じように後追いしているのね

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

288:デフォルトの名無しさん
24/03/12 20:56:37.07 Bo/PtDeL.net
>>286
常にそれをされたら困るが
Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている

289:デフォルトの名無しさん
24/03/12 22:08:56.94 qGjx1B49.net
>>274
人にキチガイと言う前に自分の脳を使って考えたら？
どちらになっても叩くことはないだろ
他の言語はデフォルトで速いハッシュを使ってるよ

290:デフォルトの名無しさん
24/03/12 22:13:42.86 qGjx1B49.net
Python　Ruby　スクリプト系言語

291:デフォルトの名無しさん
24/03/12 22:30:53.75 QLhbtBPI.net
他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹

292:デフォルトの名無しさん
24/03/13 01:06:52.67 l12NsVZP.net
他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう

293:デフォルトの名無しさん
24/03/13 01:36:16.81 yq4Sx3eg.net
Swiftも同じSipHash13だよ

294:デフォルトの名無しさん
24/03/13 06:48:44.81 vtWyM3VT.net
>>292
じゃあRustの思想は？

295:デフォルトの名無しさん
24/03/13 07:26:54.50 W15vpPlq.net
>>283
判断できない人まで言語側で救う必要性が分からない。
それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。

296:デフォルトの名無しさん
24/03/13 08:05:27.17 7ftIQ2tM.net
必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは？

297:デフォルトの名無しさん
24/03/13 11:53:59.71 k71lJTPU.net
安全と速度は両立するかそれともトレードオフか
トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね
有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない

298:デフォルトの名無しさん
24/03/13 13:08:21.45 zcdQDtji.net
Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな
賢いならRustなんかやらない

299:デフォルトの名無しさん
24/03/13 13:52:10.04 k71lJTPU.net
自由があればデフォルト設定を強制されないのは自明な事実
ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか
そもそも「所有している」というのはただの感想なのか客観的事実なのか

300:デフォルトの名無しさん
24/03/13 15:08:41.44 EtYMYlMl.net
アホ vs バカの不毛な争いが続くのは隔離スレにﾜｯﾁｮｲつけたやつの責任だからな

301:デフォルトの名無しさん
24/03/13 17:12:52.60 2jYqKDsd.net
本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。
5chでRust使ってるって言ってるやつらはそんなもの

302:デフォルトの名無しさん
24/03/13 17:32:48.34 k71lJTPU.net
不毛の判断が早いなあ
後世の歴史家が判断するという定型文に縛られないから早いんだな

303:デフォルトの名無しさん
24/03/13 17:40:34.76 EfEhvhMh.net
安全と速度を両立させたのが
RustやPythonなどが採用しているSipHash13

304:デフォルトの名無しさん
24/03/13 18:38:09.42 9N462qty.net
>>295
いや、unsafeは判断できる人が使うものだろ。

305:デフォルトの名無しさん
24/03/13 21:22:31.53 cNV/vVTe.net
>>300
分かってるんならﾜｯﾁｮｲ付きRustスレの盛り上げに協力してくれんかえ

306:デフォルトの名無しさん
24/03/13 21:54:19.69 Ay/UTMuM.net
ワッチョイなんか盛り上がる訳ねえ
そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的

307:デフォルトの名無しさん
24/03/13 22:31:42.96 /twoPXVD.net
高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話

308:デフォルトの名無しさん
24/03/13 22:39:35.15 vtWyM3VT.net
30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ

309:デフォルトの名無しさん
24/03/13 22:42:16.17 6IE1D2aF.net
出世出来ましたか？

310:デフォルトの名無しさん
24/03/13 22:52:25.45 /twoPXVD.net
能力が低下してコーディングできないのとしないのでは大違い

311:デフォルトの名無しさん
24/03/14 00:41:25.89 2hurvpo9.net
結局スクリプト言語で書かれた原作が必要か
他のジャンルでも原作なしのオリジナルは難しそうだろう

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

313:デフォルトの名無しさん
24/03/14 12:34:38.63 GaNa4vYx.net
日本みたいに、何とかするには人投入しよう！スキルどうでもいいからとにかく人集めて！なところじゃね～。

314:デフォルトの名無しさん
24/03/14 13:45:31.80 zTrHTca+.net
おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。
歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて
速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。
(それは C++ で書かれてるんだけどね。)
商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。
リンカを作ってるところはこぞって高速化に努めた。
リンカ以外にもその機運が波及しているのが今。
で、高速化のキモはデータ構造であるというのが明瞭になったんだけど
メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。
Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。

315:デフォルトの名無しさん
24/03/15 00:47:31.57 eu7fnAy5.net
コードを書けない
プログラムできなくなるとこういうことしか書けなくなると言う見本

316:デフォルトの名無しさん
24/03/15 10:43:30.71 5CgUbd5q.net
だが読むより書くほうが優れているという前提から
原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる

317:デフォルトの名無しさん
24/03/15 11:53:24.75 94MXVgRN.net
春だなぁw

318:デフォルトの名無しさん
24/03/15 18:26:51.96 5N0PtL1J.net
ai bot

319:デフォルトの名無しさん
24/03/15 20:40:42.93 W8LQpOAr.net
>>315
辛辣で草
そういう似非技術者系おじいちゃんおちょくると
怒って自分が唯一知ってる知識振り回してくるから面白いぞ

320:デフォルトの名無しさん
24/03/15 21:07:06.30 8+Y0uCh5.net
Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい
ここはRust専用スレ

321:デフォルトの名無しさん
24/03/15 21:26:31.60 PnOJWcC7.net
コーディングが出来なくなると人生はつらいと思うけどな…

322:デフォルトの名無しさん
24/03/15 21:36:49.30 3GkeGGWK.net
できなくなるんじゃなくて
元々できてないんよね>>314みたいな人は
というより単に職業マじゃないのかもな
趣味でプログラム触ったことあるパソコン少年的な

323:デフォルトの名無しさん
24/03/16 00:23:32.44 /iia2JvS.net
人はいつか何もできなくなって死んでいくんだよな
つまらないね

324:デフォルトの名無しさん
24/03/16 08:54:22.01 aeWu0EgX.net
肉屋がレッドオーシャンになれば豚はブルーだからこれでいい

325:デフォルトの名無しさん
24/03/17 19:33:58.02 1VtyMVPz.net
Rust書けるやつ集めるの大変すぎ

326:デフォルトの名無しさん
24/03/17 22:06:35.75 BMZldfUE.net
Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな
ただしまともなプログラマーしか使い　　こなせない

327:デフォルトの名無しさん
24/03/18 09:59:50.17 ySp1yGcK.net
むしろ変なやつしか使ってない感じだけど…

328:デフォルトの名無しさん
24/03/18 10:20:48.83 JObkxwF0.net
しょーもないこだわり持ってるやつしか使ってない

329:デフォルトの名無しさん
24/03/18 13:49:12.09 lCCxn1Q7.net
今後の仕事考えたらRustだね

330:デフォルトの名無しさん
24/03/18 14:26:36.03 1+ObkRXf.net
メモリ安全性ってなんなの？

331:デフォルトの名無しさん
24/03/18 14:49:59.91 RRSB5dTk.net
無効なアドレスを参照しない
運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる
無効なアドレスを更新しない
運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる
メモリリークは割とどうでもいい

332:デフォルトの名無しさん
24/03/18 15:00:45.39 ZJ4hMg34.net
>>330
メモリ安全性のうち特に重要な一つがメモリ競合の安全性
まだ使っている値を意図せずに書き換えてしまい矛盾してしまう
プログラミングで起こるバグの代表的な一つ
Rustではこれを防ぐことができる

333:デフォルトの名無しさん
24/03/18 15:02:35.53 1+ObkRXf.net
>>331
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました……

334:デフォルトの名無しさん
24/03/18 15:07:28.37 1+ObkRXf.net
>>332
ありがとう
「運が悪ければ変な値が使われて何か起こる」
そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね…

335:デフォルトの名無しさん
24/03/18 18:35:36.34 utey1W8X.net
セルフコントならもう少し面白いやつを頼む

336:デフォルトの名無しさん
24/03/20 01:19:02.24 6E76csi8.net
WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。
URLﾘﾝｸ(www.security-next.com)

337:デフォルトの名無しさん
24/03/20 05:37:59.51 wTR4SIFK.net
デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。

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

338:デフォルトの名無しさん
24/03/20 12:50:32.15 /slJg93x.net
>>336
そういうのRust関係ないからわざわざここに書かなくてもいいよ

339:デフォルトの名無しさん
24/03/20 13:00:27.22 3fTCja3E.net
関係無いわけないでしょｗ
rustで書かれてたら安全なんじゃなかったん？ｗ

340:デフォルトの名無しさん
24/03/20 13:48:07.28 i9d3tzeg.net
ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ

341:デフォルトの名無しさん
24/03/20 14:22:40.25 HLjoI2yW.net
これは「メモリ安全」の外の話？中の話？

342:デフォルトの名無しさん
24/03/20 16:11:18.74 sC/F3tDJ.net
unsafe使用箇所だからメモリ安全の外だろうな
インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない

343:デフォルトの名無しさん
24/03/20 16:33:56.60 pz7pPV/0.net
jsonの方も？

344:デフォルトの名無しさん
24/03/20 17:50:49.65 w9jt/Hdz.net
コード見てみたが言語関係なくダメな書き方の見本ってだけだな
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
修正コードは毎回境界チェックしてるのと同じ
extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない

345:デフォルトの名無しさん
24/03/20 18:13:46.74 ASk8Mk2n.net
extendという名前も実体と違ってバクの素

346:デフォルトの名無しさん
24/03/20 18:19:15.64 sC/F3tDJ.net
修正コードはhotfixでしょ
masterブランチの方は結構手が入ってると思う

347:デフォルトの名無しさん
24/03/20 18:27:22.61 ihbrcjwp.net
その知識やスキルを活かして出世して欲しい

348:デフォルトの名無しさん
24/03/20 20:04:41.25 TrbgWl+Z.net
ダメな書き方でもコンパイルが通れば安全なはずなのではｗ

349:デフォルトの名無しさん
24/03/20 20:32:22.01 sC/F3tDJ.net
んなこたない
ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる

350:デフォルトの名無しさん
24/03/21 01:05:26.83 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) }
}

351:デフォルトの名無しさん
24/03/21 01:39:19.40 t5wrhqh7.net
>>350
俺んとこもそのコードはよく書くけれど
今回の敗因は引数のindexが生のusizeであること
そこをusize直接ではなくそのラッピングの専用型にする
そしてその専用型が動く範囲が必ず範囲内であることを保証する形で
get_uncheckefのunsafeを使う関数をsafeに仕上げる

352:デフォルトの名無しさん
24/03/21 19:05:54.93 QWnK+qvS.net
unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？

353:デフォルトの名無しさん
24/03/21 19:57:12.18 7RDAu5V5.net
全然そういう事
Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい

354:デフォルトの名無しさん
24/03/21 20:09:58.67 gM/gTjZ5.net
>>353
それ言うなら
無闇に「ヤバい」を使うぐらいヤバい
じゃね

355:デフォルトの名無しさん
24/03/21 20:26:53.11 1l7zk65j.net
俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな
ガンガンunsafe使ってこーぜ！！

356:デフォルトの名無しさん
24/03/21 20:28:39.30 7RDAu5V5.net
>>354
それだと単なる自己言及だから352に対する答えとして不十分では

357:デフォルトの名無しさん
24/03/21 20:45:04.06 t5wrhqh7.net
少なくとも >>350のindex: usizeは
何らかラッピング { index: usize }と別型にすべきところ
まず範囲外のusizeでうっかり使っても型エラーにできる
そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる

358:デフォルトの名無しさん
24/03/21 21:05:14.02 7RDAu5V5.net
NonZeroとかNonNullみたいな固定条件ならいいけど
範囲みたいな可変条件だと型だけじゃ厳しいでしょ
別の条件で作られた同じ型の値を使われるかもしれないし
ライフタイムで条件と関連付けるのも限界がある
結局テストパターン増やしてdebug_assert踏むしかない

359:デフォルトの名無しさん
24/03/21 21:44:37.76 t5wrhqh7.net
>>358
もちろん二段階
まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける
次にコーディングやレビューやメンテでその専用型の動きに注視できる

360:デフォルトの名無しさん
24/03/21 22:18:44.86 cOunjWn7.net
unsafeをsafeでないのにsafeにしておいて
ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです

361:デフォルトの名無しさん
24/03/21 22:27:42.27 WuGieKPN.net
結局プログラマが色々意識してコーディングしないと安全にはならないのね
こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど

362:デフォルトの名無しさん
24/03/21 23:07:15.31 7RDAu5V5.net
unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる
実際は安全の為でもpanicで止まると困るから色々注意しないといけないし
unsafeで余計なチェック省いたり黒魔術使ったりもする
Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない

363:デフォルトの名無しさん
24/03/21 23:12:07.53 v/mpoJJ8.net
>>361
unsafeを使わなれば自動的に安全が保証される
unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される
C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない

364:デフォルトの名無しさん
24/03/21 23:22:25.34 WuGieKPN.net
いつもの人がきたｗ
結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ
Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど

365:デフォルトの名無しさん
24/03/21 23:58:23.31 z414Bs3I.net
> Rustであれば安全と思ってる人が多そう

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

366:デフォルトの名無しさん
24/03/21 23:59:21.08 t5wrhqh7.net
原則はunsafeを使うな！
これだけだ

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

367:デフォルトの名無しさん
24/03/21 23:59:51.15 XJ9dJAV6.net
unsafe使わなければ安全

368:デフォルトの名無しさん
24/03/22 09:16:28.77 IQ7X1X+j.net
まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。
それは意識して気をつけた方がいい。

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

370:デフォルトの名無しさん
24/03/22 11:58:26.79 7Rs7masV.net
>>358
0～127の範囲のみを取りうるようなEnumなら作れる
wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど

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

371:デフォルトの名無しさん
24/03/22 12:34:01.41 TbCMvv+/.net
実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい
そうすればその型に対して常に安全にget_uncheckedを使える

372:デフォルトの名無しさん
24/03/22 14:04:42.65 ZrfX32kv.net
Rustは失敗言語

373:デフォルトの名無しさん
24/03/22 14:10:55.04 ceR9yHkM.net
今回の件でRustの安全性が確実になったのが興味深いよな
アンチが必死に探してきた問題も>>350でunsafe利用だった

374:デフォルトの名無しさん
24/03/22 16:00:31.63 JqYXTM4B.net
>>371
「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど
実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ
unsafeにする意味がない

375:デフォルトの名無しさん
24/03/22 17:14:19.13 vuLWDWdh.net
>>374
実行時コストをかけないためにget_uncheckedを使うのが一般的
その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法)

376:デフォルトの名無しさん
24/03/22 19:27:28.32 G6tKD1fj.net
Adaなら特定の範囲の型作れるみたいよ

377:デフォルトの名無しさん
24/03/22 20:07:18.97 vuLWDWdh.net
今回は範囲が固定ではなく変わり得る

378:デフォルトの名無しさん
24/03/23 23:29:45.64 eeq00BcS.net
誰にでもunsafeが使えてしまうのが問題なのでは？
原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。

379:デフォルトの名無しさん
24/03/24 00:34:36.37 iaJ2USO3.net
Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。
まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。

380:デフォルトの名無しさん
24/03/24 10:55:06.56 UXqlkypu.net
>>375
「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら >>350の引数のindexをその型に変えたところでsafeにしたらダメだよ

381:デフォルトの名無しさん
24/03/24 11:08:34.82 BHU0SFkf.net
なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？

382:デフォルトの名無しさん
24/03/24 11:48:11.45 uu8/yG2s.net
indexの境界チェックが律速になるようなコード書いてみてえな

383:デフォルトの名無しさん
24/03/24 20:37:14.59 YsO86RjG.net
>>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー　配列もその範囲指定で自由に作成できる。

384:デフォルトの名無しさん
24/03/24 20:45:58.90 Rrl8qRWO.net
>>383
定数じゃなければ結局実行時にチェックするってことだよね

385:デフォルトの名無しさん
24/03/25 01:12:47.74 yMlw6u5B.net
>>384
新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。

386:デフォルトの名無しさん
24/03/25 07:21:41.59 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;

387:デフォルトの名無しさん
24/03/25 14:37:28.19 x/lXcXel.net
今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど
そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね

388:デフォルトの名無しさん
24/03/25 16:23:44.40 9GDk/VLW.net
How much does Rust's bounds checking actually cost?
URLﾘﾝｸ(blog.readyset.io)

389:デフォルトの名無しさん
24/03/25 17:27:16.04 MT/jL+52.net
こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。
問題は浮動小数の取り扱いだっての。

390:デフォルトの名無しさん
24/03/25 21:23:48.62 x/lXcXel.net
unsafeは可能な限り避けるべきで
safe Rustでの改善をまずすべき
その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える

現実にはsafe Rustでの改善ができてないことが多い
例えばよく見かける例としては
iが動いていくのにa[i]でアクセスしてしまう
これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern
参照(ポインタ)化することで範囲checkを1回に減らせる

391:デフォルトの名無しさん
24/03/27 15:06:55.14 g9hYSxJr.net
unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね
unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事

392:デフォルトの名無しさん
24/03/27 15:29:03.70 pFQTMi8v.net
「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」
が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので

393:デフォルトの名無しさん
24/03/27 16:02:47.08 BwG0n/Az.net
unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。
unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？

394:デフォルトの名無しさん
24/03/27 16:59:36.71 LwoOYerE.net
>>393
そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。

395:デフォルトの名無しさん
24/03/27 17:05:39.09 6Vj8sISV.net
>>392
センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ
今はそれが全然できてないから >>350のような基本的なミスを犯すやつが後を絶たない

396:デフォルトの名無しさん
24/03/27 17:08:09.55 6japDZ8y.net
windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。

397:デフォルトの名無しさん
24/03/27 18:09:17.85 345wycOn.net
>>395
～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。

398:デフォルトの名無しさん
24/03/27 18:27:03.05 3NgGdhlw.net
>>397
問題点の指摘や解決策の提案と
問題解決のために実際に誰が動くのかという
2つの異なるものを混同したらだめだよ
マネジメント101

399:デフォルトの名無しさん
24/03/27 18:54:43.86 nHNmKGrp.net
その素晴らしい提案がなぜされていないのか考えよう
そしてなぜ自分は実行から逃げているのか考えよう

400:デフォルトの名無しさん
24/03/27 20:42:45.86 deTzlgug.net
>>394
Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。

401:デフォルトの名無しさん
24/03/27 21:06:58.89 LwoOYerE.net
unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。
危険な操作も含まれるけど危険な部分を分けれてるわけではない。
もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。

402:デフォルトの名無しさん
24/03/27 21:18:47.87 deTzlgug.net
>>401
安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。
デフォルト禁止でもいいくらい。

403:デフォルトの名無しさん
24/03/27 21:31:01.25 LwoOYerE.net
>>402
だからそうしたいならそうすりゃいいって話をしてる。
あなたが裁量権をもつプロジェクトでは。
私が反論してるのは「そのためのものだ」という部分に対して。

404:デフォルトの名無しさん
24/03/27 21:44:58.62 deTzlgug.net
>>403
Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。
unsafeはデフォルト禁止でいいよ。

405:デフォルトの名無しさん
24/03/27 21:49:49.48 Fy0R0co2.net
理想をいえばunsafeなんて無いならサイコーだったんだろうね
rust陣営もしゃあなしでunsafe導入したんやろうし
unsafeなしですべてがセーフで効率的だったら
そりゃあrustは本当に素晴らしい文句なしの言語だったやろな

406:デフォルトの名無しさん
24/03/27 22:08:33.46 toZsv7uT.net
生ポインタすなわちCPUによるメモリアクセスはunsafe
そこが出発点
unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる
それがsafe Rustの基本原理
つまりunsafeに行き着くためunsafe無しでは何もできない
これが真理
一方で
unsafeを閉じ込めたライブラリ利用可を前提にすれば
unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実

407:デフォルトの名無しさん
24/03/27 22:24:02.18 cgbLYCC5.net
>>406
だったらデフォルトunsafe禁止で良い。
どこでもunsafe okはやっぱりチグハグ。

408:デフォルトの名無しさん
24/03/27 22:52:47.09 qNf/D02g.net
そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？

409:デフォルトの名無しさん
24/03/27 22:57:38.14 LwoOYerE.net
>>404
「そうであって欲しいと自分は思っている」なら別にいいよ。
ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。

410:デフォルトの名無しさん
24/03/27 23:02:28.02 toZsv7uT.net
#![forbid(unsafe_code)]
を宣言すればいい
もちろんすべてはunsafeへ行き着くため
unsafeを禁止できるのは自分のコード部分だけ

411:デフォルトの名無しさん
24/03/27 23:55:45.93 pFQTMi8v.net
unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな
平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する

412:デフォルトの名無しさん
24/03/28 07:44:09.91 OabXy/xk.net
>>409
公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。
>>411
拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？

413:デフォルトの名無しさん
24/03/28 08:15:17.48 wHq/ItvK.net
rustもいろいろ問題を抱えてるんだね
プログラマの習熟が必要だっていうなら流行らないだろう
メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし
新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう

414:デフォルトの名無しさん
24/03/28 08:34:31.08 5loDhjzb.net
>>412
こう書くだけでunsafeの使用が禁止されます
#![forbid(unsafe_code)]
>>413
普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません

415:デフォルトの名無しさん
24/03/28 08:48:28.49 OabXy/xk.net
>>414
>411みたいなマキャベリガイジが混ざると破綻しますな。
MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。

416:デフォルトの名無しさん
24/03/28 09:00:19.29 5loDhjzb.net
>>415
これでunsafeが使用禁止となり安全なsafe Rustになる
#![forbid(unsafe_code)]
コンパイラがunsafeをエラーとして弾く

417:デフォルトの名無しさん
24/03/28 10:37:24.50 dWo+4s1T.net
結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな

418:デフォルトの名無しさん
24/03/28 14:03:58.90 61/ABBlz.net
まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。

419:デフォルトの名無しさん
24/03/28 17:41:01.08 Li+1uESY.net
unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者
一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる
もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、
その部分だけを切り出してライブラリ作成者になれる
それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない

420:デフォルトの名無しさん
24/03/28 18:27:15.03 OabXy/xk.net
>>419
そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。

Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。

421:デフォルトの名無しさん
24/03/28 18:35:39.73 2Ez7VURh.net
unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが
このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう

でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ

422:デフォルトの名無しさん
24/03/28 18:56:54.80 Hx0Q8eMq.net
必要な各企業、各プロジェクトなどで義務付け
#![forbid(unsafe_code)]
これでunsafeの話はおしまい

他の言語と比べてRustはコーディング規約もAPI規約も公式で楽
Rust公式APIガイドライン
URLﾘﾝｸ(rust-lang.github.io)

423:デフォルトの名無しさん
24/03/28 19:45:10.84 OabXy/xk.net
>>422
公式のドキュメントで
#![forbid(unsafe_code)]
の説明を探しているんだけど、どこにあるのかしらん？
doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
の１行でおしまい？

424:デフォルトの名無しさん
24/03/28 20:08:10.91 uNPCtnZO.net
forbidもunsafe_codeもrustcのlintの一部だな
doc.rust-lang.org/rustc/lints/levels.html#forbid
doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code

425:デフォルトの名無しさん
24/03/28 21:59:19.02 vhhc95Ef.net
Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。

次ページ