- Rust Part5
318 ：デフォルトの名無しさん[]：2018/04/12(木) 01:27:42.33 ID:JdbozTc/ - 久しぶりに見に来たらアンチが帰ってきてるじゃん。
せっかくだから、おれも反論レスを書き込むことにする。
|
- Rust Part5
319 ：デフォルトの名無しさん[]：2018/04/12(木) 01:28:00.22 ID:JdbozTc/ - >>288
こんなこと言っちゃってる時点でセキュリティに気を使ってないのバレバレだよね
セキュリティ関係に詳しくなくて分からないんなら素直に分からないって言いなよ
|
- Rust Part5
320 ：デフォルトの名無しさん[]：2018/04/12(木) 01:28:37.08 ID:JdbozTc/ - >>299
unsafeなんてC FFIしようとか考えない限りあまり使うことないよ
tokio-coreとかhyperとかhtml5everとかのソースコード見てきなよ
unsafe使ってる箇所なんて10箇所あるかないかってところだから。
コード全域に気を配らなきゃならないのか、たった10箇所程度に気を付けてれば良いのか、
どちらが楽(安全)なのかは火を見るよりも明らかだよね
|
- Rust Part5
321 ：デフォルトの名無しさん[]：2018/04/12(木) 01:30:08.73 ID:JdbozTc/ - >>303
これに関しては自分がC FFIのコードを滅多に書かないから「そうだったっけ？」くらいにしか考えなかったけどよく考えたら全然違うよね。
まず、値渡しなら引数・戻り値ともに何の問題もない。そのまま渡せばいい。
ポインタ渡し(Box<T>)だった場合はCの関数の引数が所有権か借用のどちらを欲してるのかを確認して、
所有権を欲しがってるならBox::into_raw(x)で所有権を渡せばいいし、
借用が必要ならx.as_ref() as *const _ もしくはx.as_mut() as *mut _で渡せばいい。
戻り値の方ではC側から所有権が渡されてるはずだからBox::from_raw(px)でBox<T>に戻せばOK。
文字列(String)の場合はCStringに変換してから後はBox<T>と同様にinto_raw, from_raw使えばいいだけ。
Vec<T>とかを渡そうとする場合はx.as_ptr()またはx.as_mut_ptr()と場合によってはmem::forget(x)が必要になるんじゃないかな？
受け取る場合はVec::from_raw_parts(px, len, cap)を使えばいいはず。(前述のとおりC FFIはあまり詳しくはないので間違ってたら指摘して下さい)
unsafeの中に何を書けば良いのかはC側のどんな関数を呼ぶのか次第で変わってくるけど、少なくともDropトレイトに関しては全く必要ない。
Box<T>やVec<T>等にあらかじめ実装されてるDropトレイトに任せればいいだけ。むしろ君はDropトレイト使って一体何する気だったのか…？
|
- Rust Part5
322 ：デフォルトの名無しさん[]：2018/04/12(木) 01:30:27.15 ID:JdbozTc/ - Rustのアンチするのは一向に構わんが、せめて嘘をつくのはやめようね。
|
- Rust Part5
328 ：デフォルトの名無しさん[]：2018/04/12(木) 13:14:59.37 ID:JdbozTc/ - >>325
>>303は「メモリリーク」って書いてあるからヒープに確保されたメモリの解放に関しては
Dropトレイトを実装する必要性なんか全く無いってことを>>321で説明してる。
>>325の言ってる「リソース」ってのはファイルとかソケットとかのことを言ってるんだよね
そっちはメモリリークとはまた別の話になるので状況によるんじゃないかな…
ただ、OSが提供してるリソース(ファイルやソケット)くらいなら、File, TcpListenerとかには
Windows用とUnix用にそれぞれinto_raw_xxx(), from_raw_xxx(), as_raw_xxx()とかが用意されてるから
それを使えば後のことはFile, TcpListenerのdrop実装に任せてしまって問題ないはず。
C側(ライブラリ)で独自に実装されてるリソース(close等の後処理が必要な実装)の場合は
close部分をRustのDropトレイトの実装として移植する必要はあるだろうね。
(もう一度言うけど、自分は普段はC FFIを使わないから詳しくはないので、間違ってたら指摘して下さい)
|
- Rust Part5
330 ：デフォルトの名無しさん[sage]：2018/04/12(木) 17:39:03.84 ID:JdbozTc/ - >>329
ちょっと言ってる意味がわからない
Cでmallocされたものであっても所有権ごと渡されていれば解放の責任はRustにある
ていうか、Rust側で勝手に解放しちゃいけないと言ってるのに
Dropトレイトの実装でfreeしたらやっぱりRust側で勝手に解放しちゃってるじゃん
言ってること矛盾してない？
CとRustで型のメモリレイアウトが一致してればあとはBox型に任せるだけだよ
Cから渡されてくるポインタの型のメモリレイアウトが公開されていなければ
(つまりvoidポインタだったりオペーク構造体(オペークポインタ)だったなら)話は別だけど。
その場合はRustはハンドルをもらうだけでいかなる操作(メモリの解放(free)も含む)もC FFIでC側に
頼むしかない(メモリレイアウトがわからない限りはRust側ではどうあがいても何も出来ない)ので
Dropトレイト実装してdrop時にC側にメモリの解放処理も頼む必要がある
|
- Rust Part5
333 ：デフォルトの名無しさん[]：2018/04/12(木) 22:43:32.09 ID:JdbozTc/ - >>322
だったら「Rust側からはメモリレイアウトが分からないようなvoidポインタや
オペーク構造体がC側から渡された場合は」という前提条件をきちんと書け。
条件を何も書かずに「drop trait を明示的に書かなきゃならん」とだけ書かれれば
全ての場合で必要だと言っているようにしか見えない。
あと、>>321で「全く」と書いてしまったことは悪かったと思っている
>>321を書いてる時点は上記のような可能性に気づいていなかった…申し訳ない。
お前みたいに「特定の条件下でしか適用されないこと」に対して条件を書かずに結論だけ書いて
「自分はきちんと伝えた」とか思っちゃってるキチガイとの仕事とかこっちの方から願い下げだから。
|
- Rust Part5
334 ：デフォルトの名無しさん[]：2018/04/12(木) 22:50:55.21 ID:JdbozTc/ - >>331
そこは自分も同じことを思った。
mallocとjemallocの実装の中身とか見たことないけど、混在してても問題ないのかな？
|
- Rust Part5
335 ：デフォルトの名無しさん[]：2018/04/12(木) 22:54:07.42 ID:JdbozTc/ - >>333 訂正
>>322 → >>332
|
- Rust Part5
337 ：デフォルトの名無しさん[]：2018/04/12(木) 23:35:57.15 ID:JdbozTc/ - >>336
マジか…mallocとjemallocは混在できないのか…
そうなると、C側でmallocされてれば必ずC側にfreeしてもらうしかないということか…
じゃあ今まで俺が書いた方法じゃダメなケースもあるじゃん…すまん。
自分の無知を晒す羽目にはなったが、むしろ今知れてよかったわ。
でも、そうなると新たな疑問が…
|