Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
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 part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/20(金) 13:47:00.37

>>827
C++はそのようなデータ競合を見逃すけど
Rustはコンパイルエラーにしてくれる

let mut v = vec![0, 1, 2, 3, 4, 5, 6, 7];
let p5 = &v[5];
v.push(8);
assert!(*p5 == 5);

error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
|　let p5 = &v[5];
|　　　　　　- immutable borrow occurs here
|　v.push(8);
|　^^^^^^^^^ mutable borrow occurs here
|　assert!(*p5 == 5);
|　　　　　--- immutable borrow later used here

**デフォルトの名無しさん** · 2024/09/20(金) 14:22:18.97

>>966
そういうのはもうおなか一杯だから
Cで出来るのにRustで出来ないことを挙げてよ

**デフォルトの名無しさん** · 2024/09/20(金) 14:47:29.30

>>966
シングルスレッド上で同一アドレスに読み書きが発生することをデータ競合とは言わない
https://en.cppreference.com/w/cpp/language/multithread#Data_races
https://doc.rust-lang.org/nomicon/races.html

**デフォルトの名無しさん** · 2024/09/20(金) 15:06:48.25

>>827がシングルスレッドでもデータ参照に競合が起きてバグが発生している例
>>966がシングルスレッドでもデータ参照の競合をコンパイラが検出してバグを防いでいる例

**デフォルトの名無しさん** · 2024/09/20(金) 15:27:19.87

>>969
>>827のASAN実行結果
AddressSanitizer: heap-use-after-free

$ clang++ -O1 -g -fsanitize=undefined,address -fno-omit-frame-pointer main.cpp -o main
$ ./main
=================================================================
==26132==ERROR: AddressSanitizer: heap-use-after-free on address 0x...
WRITE of size 4 at 0x... thread T0
#0 0x7ff62e7716d4 in main ~/main.cpp:15:9
...

0x... is located 20 bytes inside of 32-byte region [0x...,0x...)
freed by thread T0 here:
...
#9 0x... in main ~/main.cpp:13:7
...

previously allocated by thread T0 here:
...
#7 0x... in main ~/main.cpp:5:22
...
...

**デフォルトの名無しさん** · 2024/09/20(金) 15:35:56.11

このようにC++だとサニタイザーで実行するまでわからない
レアケースで発生するものだと実行しても何日間も見つからないこともある
そして本番へ投入してレアケースが発生して大惨事となる
つまりサニタイザーでは本質的な解決にならないのだ
Rustのように実行せずともコンパイル時に確実に判明することが正しい解決策だ

**デフォルトの名無しさん** · 2024/09/20(金) 15:36:26.98

>>827のような操作がバグかどうかは状況による
Rustがやってるのはバグと見做されるような挙動を生みやすいパターンを弾く安全側のアプローチ
言語によっちゃ同名変数の宣言によるシャドウイングを禁止してたりするが、それと似たようなもんだ

**デフォルトの名無しさん** · 2024/09/20(金) 15:41:33.93

>>972
開放された無効領域を指すダングリングポインタとなっている>>827は明確なバグ
セキュリティホールにもなりうる深刻なバグ

**デフォルトの名無しさん** · 2024/09/20(金) 15:51:51.16

>>973
それはpush_backの実装がたまたま領域を解放しうるから結果的にバグなだけで、
Rustのチェックがそこまで考慮してこのエラーを出しているわけじゃないでしょ
安全側に倒した結果としてたまたまバグを検出できた例と考えるのが適切

**デフォルトの名無しさん** · 2024/09/20(金) 15:51:55.07

>>959
政治的な理由でマージされないなら、それは記述されているとは言えない

**デフォルトの名無しさん** · 2024/09/20(金) 16:13:04.26

>>966,971が裏でJS/TS書いてると思うとほっこりする

**デフォルトの名無しさん** · 2024/09/20(金) 17:24:13.84

>>974
結果的も何も、たまたまも何もバグじゃん。
バグは早期に発見できるほうがいいだろ。

**デフォルトの名無しさん** · 2024/09/20(金) 18:37:17.32

>>974
↑こういう認識だからいつまでたってもバグがなくならない
主要なOSやブラウザで毎年数千単位の脆弱性が出てる現実を分かってない

**デフォルトの名無しさん** · 2024/09/20(金) 18:46:47.16

今rustでグラフィックスプログラミングって実用的？
dx12とかvulkanとか
いい加減c++捨てたいと思ってるけどrustで性能でないなら使えない

**デフォルトの名無しさん** · 2024/09/20(金) 18:57:32.01

>>974
一般的に参照を保持したままそのデータへの別の可変参照が用いられる(＝データが書き換わる)と
意味論的に最初の参照が期待していたものと異なるデータ状態になっている可能性があるためバグの発生要因となる
その例のうち最も極端なものがデータがメモリ開放されてしまっているベクタ伸長による自動メモリ移動の例
もちろんメモリ開放を伴わなくてもデータの状態が変わってしまって意味論的に食い違いが起きることでのバグが生じる
特に複雑な状況だとその食い違いが起きていることを人間が把握しきれなくなり見落としてしまう
Rustではそのようなデータ参照の競合を検出してコンパイルエラーにしてくれるため安全である

**デフォルトの名無しさん** · 2024/09/20(金) 19:02:50.08

>>977,980
Rustはコンパイルが超遅いから、Rustがコンパイルエラーを吐くより先に、C++がコンパイルとサニタイザー検出を終えてるだろ

**デフォルトの名無しさん** · 2024/09/20(金) 19:28:29.22

>>981
サニタイズはプログラムを実行しなければならず更に問題が発生する条件がたまたま揃うまで無限に待たなければいけない
したがって必ずしも問題が検出できるとは限らない非常に劣った方法
しかも対象領域がメモリ問題などいくつかに限られた項目のみ
Rustはデータ参照競合を一般的にコンパイル時点で確実に検出できる

**デフォルトの名無しさん** · 2024/09/20(金) 19:54:50.23

>>982
データ競合の間違い指摘でデータ参照競合と言い出す奴