Rust part37

公式
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 part36
https://mevius.5ch.io/test/read.cgi/tech/1779974768/

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

>>134
また荒らしが出るからあんま上げんなよ

572 デフォルトの名無しさん sage 2026/07/01(水) 01:14:29.65 ID:E4CfZuIc
Announcing Rust 1.96.1
https://blog.rust-lang.org/2026/06/30/Rust-1.96.1/

573 デフォルトの名無しさん sage 2026/07/01(水) 02:21:36.27 ID:5WKZWNdO
原因が辛いな

CVE-2025-15661
Updated: 2026-06-23
Title: libssh2 - Heap Buffer Over-read via sftp_symlink() in sftp.c

CVE-2026-55200
Updated: 2026-06-18
Title: libssh2 - Out-of-Bounds Write via Unchecked packet_length in transport.c

Cのせいにするなとか被害妄想してる奴が湧いたアプデだろ

sshもRustで書き直すしか

おじいちゃん起きたのね

複オジが逆認定するようになったのか
書いてる内容バレてるのにな

複オジが不要にスレ伸ばすときは
その直前の恥ずかしいレスを流したいとき

ID:S/Q9GBk8, ID:bhJjxK5U, ID:PQcA2rQz, ID:9maZOq/z, ID:csslsvGN, ID:tnY5WOXG, ID:nqHGciLl, ID:3wFsDlQx

今日の複おじID

>>141
これ

だから複おじはスレ上げたがる

その脆弱なlibsshをRust化すべき

授乳してくる

複オジは荒らしでかつIDコロコロするから印象が悪い

Rustアンチの障害者
脳みそC++

>>147
もしかして複おジ

>>149
何言ってんだこいつ

>>145
既存資産が一斉に入れ替わらんのはしゃーない

Rustは書きやすいからいいわ
Pythonくらい当たり前になっていい

Pythonで書いて、AIにRustへ移植させた方がいい

あっちこっちのスレが複おじに汚染されてるな
伸びてるスレは特に

自分が気に食わない奴を雑に複おじ認定してるだけだろ

Pythonで書いてRustに移植させるとか無駄すぎる
最初からRustで書けばいい

慣れてしまえば制約がキツイと思い込んでいたRustがほとんど自由に書けることに気付く

自然とイメージできるようになるよな

Rustはかなり自由
どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる

>>159
また複おじがめちゃくちゃ言ってるな

もう放っとけよ、前スレからずっと同じコピペで荒らしてる奴だし

>>159
まあそう思うならRust書いてみたら？
入門書のリンクも貼っといてやるからさ
https://doc.rust-jp.rs/book-ja/

>>159
それは出来て当たり前
出来ないことは手元にある値の参照を返すことだけ

ライフタイムについて知らないド素人もおるんやなあ

>>163
出来て当たり前じゃなくて、同期処理してる時だけだぞ

同期処理してれば当然できる
親の方が子より長生きで当然

非同期だとできないこともある
親の方が子より長生きとは限らない

非同期でも>>159の文章は必ず成り立つ

>>167
ArcやRcも参照に入れればそうやな

参照カウント式の管理を「参照」だけで語るのは流石に無理かな
それも「必ず」と言ってしまってるわけで

関数って呼ばれるものの幅って結構広いからね
たぶん>>167の想像にないものがある

そもそも参照って曖昧にせずに借用って言えば解決する

cargo check通れば安全と同じこと言いたいんじゃね

>>159の関数がasync関数でも成立してる

流石に色々無理が生じてきてるなあ

>>168
ArcやRcは参照ではなく所有

>>172
どんなテストでもツールでもそれだけを妄信しちゃいかんのにな
「必ず」とか言い出す奴はだいたいダメ

>>159は必ず成立する
反例はない

関数の範囲をできるだけ狭めて、参照の範囲をできるだけ広げれば、はい

定義を都合よく曲げるのはよくない

参照は&Tだろ
関数はfnだろ
async fnでも同様に>>159は成立

いかなるライフタイムでもと言い切ってるからなあ
それだと成立しないと思われる
「コンパイルが通れば」みたいな言ってない条件を勝手に追加してそう

「どんな参照でも必ず返せる」は「いずれかの参照なら必ず返せる」とは真逆の意味なんでなあ
全部返せないと成立しない

少なくとも>>159は任意のライフタイムで必ず成立する
成立しないと思う人は反例コードを示せばいい

弱参照を受け取ってそれを通常の参照に変換して返す関数を書いてみて

今のAIだとこのくらいは簡単か

しょうがないにゃあ

fn foo<'a, 'b, T>(o: &'a mut Option<&'b mut T>, v: &'b mut T) -> &'b mut T {
*o = Some(v);
v
}

>>184
弱参照は指す先が無効になってる場合も安全に扱えるようにするためのもの
だから参照への変換は原理的に不可能
弱参照自体は返すことがてきる

>>186
それは可変参照が借用中に同時に可変参照を使えないだけ
借用を終えたら可変参照も返すことができる

ここまでに>>159の反例コードを示せた人なし

どんどん条件付け足して反例なしって言うの不毛すぎる

どんな参照でも返せるって言ったんだから、ID:GVCMKu1fは言い訳してないで条件を変えずに通せる方法を書けよ

そもそもどんな参照でもどんな関数でもって条件だから、他のスレッドから借用した場合も対象だよね
しかも条件を何もしてしてないから、本体側のスレッドが先に死んでもいい
これはコンパイルを絶対に通らない条件なので不成立だけど、どんな参照でもどんな関数でも返せるという主張の反例にはなってる
まあ、また条件を増やすかもしれないがｗ

>>191
新たな条件を一つも加えていない
引数で受けた弱参照も必ず返せる
引数で受けた可変参照も必ず返せる
今回の元の文章は以下のように書かれている

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

>>192
それは以下の反例になっていない

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

そのうち「コンパイルを通る場合で」とか言い出しそう
コンパイルを通るならボローチェッカーの検証済みだから必ず成立する、だからこの条件でトートロジーにできる

>>194
thread::spawnは関数じゃマヌケ

早すぎて笑った

つまり>>192は
どんな寿命の参照でも → 当然 ○
それを関数の引数で受け取ったら → thread::spawnは関数なので ○
その参照や一部の参照を、関数から必ず返せる → 本体側のスレッドが先に死んだら不成立 ×
ってことか

>>196
参照を引数に取らない関数も参照を返さない関数も無数にあるのは当たり前
それは無関係な話
自分で作る関数が引数で受けた参照を常に返せるかの話しかなされていない

>>199
また勝手に条件増やしてて草

>>200
条件は一切増えていない

>>199
スレッドを作る関数を自分で作れないとする根拠がないと成り立たない主張だということは気付いてるのか？ｗ

>>201
ハイ嘘
> 自分で作る関数が引数で受けた参照を常に返せるかの話しかなされていない
こんなことはここまで言っていない

>>202
もちろん何を作っても構わない
以下は必ず成立する

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

>>204
ハイ嘘
thread::spawnと同じ機能を持つ関数を作ると不成立

しかもシステムコールするだけの結構簡単な関数なの草

>>205
それは以下に明記されてる前提を満たせないから明らかに対象外
「関数の引数で受け取ったら、」

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

>>195
そろそろ本当に「返せるように書けば」って言いそうｗ

>>207
どう見てもthread::spawnは引数で受け取ってますねｗ

関数の引数で受け取ったら ←これは疑う余地ない件
むしろ参照をスレッドに渡す設計はよくないとか言って話をそらした方がまだ戦えるレベル

>>209
spawnの引数が何なのか知らない無知な人は勉強して出直してきてね

>>211
「引数で受け取ったら」って書いたのはお前じゃいｗ
「引数に参照を取る関数」なんて書いてない

thread::spawnの引数で参照を扱うことはもちろん可能
実際 'static ライフタイムになっていれば受け渡せる

Rustでは付加条件なく必ず成り立ちます

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

>>214
ついに反論できなくなって逃げたな
反例: thread::spawn()

そもそも「引数に参照を取る関数」に書き換えたところでそういう引数を受け取るようにスレッドを作る自作関数を作ればそれで成り立たなくなる模様

>>215
反例になっていない
まずspawnの場合は引数はクロージャ
クロージャでキャプチャされてきた参照は必ず返すことができる

>>217
「引数で受け取ったら」って書いたのはお前
「引数に参照を取る関数」なんて書いてない

>>216
まずは>>159の反例コードを作ってみたら？
まだ誰も示せてないから

Pin止め忘れたFutureの参照はどう？
条件に合ってるけど死なないかな
だからUnpin設計する羽目になったわけだし

「どんな寿命の参照でも」って言いきった以上今更「返せる寿命なら」って言ったらそれはそれで条件を変えてる

>>218
論理が苦手なのかな
>>159の反例を示せないといけないんだよ

>>222
アホめ
そっちは「他の関数から返ってきたものでも」とも書いてるから余計にドツボなんじゃ

>>221
どんな寿命の参照でも大丈夫
Rustではそれを関数の引数で受け取ったら関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

元より条件狭めてもなお敗北してるの草

>>223
もし反例があるならRustコードで示しましょう

>>224
反例: thread::spawn()

>>226
反例: thread::spawn()

>>225
条件は以下の元の文章一切変更していない
この元の文章のまま必ず成り立つ

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

>>229
反例: thread::spawn()

>>227
spawnでも成り立ってますよ
指定クロージャがキャプチャしてきた参照は必ず'staticになるため必ず返すことができます

>>231
あ、ついにやったな
バレないと思ったかもしれないがそれは渡された参照が 'static の場合だけ
こっそり「どんな寿命の参照でも」を消してる

なんでこんな偉そうにしてる奴がいたら全力で叩きたい連中のたまり場でここまでツッコミどころ満載のイキり発言をしてしまったのか……

>>232
もちろん
どんな寿命の参照でも
『それを関数の引数で受け取ったら』
必ず返せます

元の書き込み
>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

>>234
反例: thread::spawn()

あと、元の書き込みを印籠にしたいなら
> どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる
もちゃんと書いとけマヌケ

>>235
まずspawnの仕様をよく見ようよ
spawnには'staticしか来ない
だからspawnの場合も以下が成立している

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる