Rust part27 (388ﾚｽ)
Rust part27 http://mevius.5ch.net/test/read.cgi/tech/1733146370/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
246: デフォルトの名無しさん [sage] 2025/01/30(木) 00:26:18.93 ID:N5Ev4mKi str <-> OsStrの話は差異をうまく隠蔽しにくくシグニチャに影響しうるというのがあるけど仮に影響しなくても境界で変換するのが望ましいという判断は変わらなかったはず http://mevius.5ch.net/test/read.cgi/tech/1733146370/246
247: デフォルトの名無しさん [sage] 2025/01/30(木) 00:39:30.16 ID:N5Ev4mKi https://github.com/rust-lang/rfcs/pull/575 https://github.com/rust-lang/rfcs/blob/master/text/0517-io-os-reform.md#string-handling http://mevius.5ch.net/test/read.cgi/tech/1733146370/247
248: デフォルトの名無しさん [sage] 2025/01/30(木) 20:50:11.01 ID:DEHLqPyE >>247 ありがとう、RFCのほう探せばよかったのか > ## Wide string representation > Downsides: > * These conversions have inconsistent performance characteristics between platforms. (Need to allocate on Windows, but not on Unix.) やっと納得できる理由が出てきた、これはたしかにな…いやでもなあ、直接OsString/OsStrを触るAPIがもっと充実していれば別にString/strとの変換をそこまで気にする必要もないのでは？ 一気にString/str相当のAPIを実装するのも手間だし、OsString/OsStrで何かやりたかったらとりあえずString/strと変換してなんとかしてくれ、だからここではプラットフォームごとの差を付けたくない、って方針だったのかね？ とはいえ、考えられる発展としていろいろな文字列型を一般化する抽象化を作れるはずとかちゃんと書いてあるし、まあまあ納得できる経緯説明ではある ありがとうね > // and ultimately other functionality typically found on vectors, > // but CRUCIALLY NOT as_bytes …とか書いてるけど、今は普通にas_encoded_bytesとして実装しちゃってるし、結局なんだかよく分からんなあ http://mevius.5ch.net/test/read.cgi/tech/1733146370/248
249: デフォルトの名無しさん [sage] 2025/01/30(木) 23:18:13.05 ID:tIaEaP36 >>248 >> * These conversions have inconsistent performance characteristics between platforms こう書かれてるけどパフォーマンスという点では特にDownsideじゃないと思うんだけどね 今の実装でも発生してるし違う環境用のOsStringを1つのプログラムが実行時に混ぜて扱うわけでもないし 問題なのは内部コードにアロケーションタイミングの違いみたいなのが侵食して分岐が増えること わかりやすい例としてはOsStr::new(“foo”)が&OsStrを返せなくてCow<OsString, OsStr>になるとか http://mevius.5ch.net/test/read.cgi/tech/1733146370/249
250: デフォルトの名無しさん [sage] 2025/01/30(木) 23:38:58.04 ID:dm9clnkq そうだね だから現状の仕様で正しくて 10年間も問題視されていない 許容できない用途が仮にあるならWindows専用のクレートを作ればいい http://mevius.5ch.net/test/read.cgi/tech/1733146370/250
251: デフォルトの名無しさん [sage] 2025/01/30(木) 23:54:08.19 ID:tIaEaP36 as_encoded_bytesの話はこれ https://github.com/rust-lang/libs-team/issues/306 http://mevius.5ch.net/test/read.cgi/tech/1733146370/251
252: デフォルトの名無しさん [sage] 2025/01/31(金) 02:25:28.04 ID:r6oh8F22 > # Alternatives > * A split_at(&self, pos: usize) -> (&OsStr, &OsStr) style method. This is ostensibly simpler than a slicing API. But: > ** The OMG-WTF-8 encoding does not support this. It requires some splits to produce overlapping slices, so that left.len() + right.len() > orig.len(). The encoded bytes on one side of pos might form a valid OMG-WTF-8 string while those on the other side do not. > *** RFC #2295 that proposes this encoding was merged five years ago (but has not been implemented). 何その絵に描いた餅を喉に詰まらせて死ぬみたいな話…… http://mevius.5ch.net/test/read.cgi/tech/1733146370/252
253: デフォルトの名無しさん [sage] 2025/02/03(月) 22:01:34.61 ID:QOxyx9oM ほとんどのシステムはUTF-8以外のファイル名があったら無視かエラーでいいからどうでもええわ http://mevius.5ch.net/test/read.cgi/tech/1733146370/253
254: デフォルトの名無しさん [sage] 2025/02/06(木) 13:08:01.16 ID:s+irydGq https://mevius.5ch.net/test/read.cgi/tech/1691038333/514-528 ﾜｯﾁｮｲ付いてないとどこにでも出るな妖怪 http://mevius.5ch.net/test/read.cgi/tech/1733146370/254
255: デフォルトの名無しさん [sage] 2025/02/07(金) 13:12:05.02 ID:2gmcoh6P LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中 - TechFeed https://techfeed.io/entries/67a52d4677bdbc0f2990eed9 争え……もっと争え…… http://mevius.5ch.net/test/read.cgi/tech/1733146370/255
256: デフォルトの名無しさん [sage] 2025/02/07(金) 21:47:52.74 ID:Q2ziLxl4 Linusが一喝するまで収めるの無理やろ http://mevius.5ch.net/test/read.cgi/tech/1733146370/256
257: デフォルトの名無しさん [sage] 2025/02/07(金) 22:08:06.65 ID:lN1GxRH8 そりゃドライバーはカーネルのインターフェイスに従って動作すべきだから、ラッパーなりで隠蔽すべきなんじゃないんかね。 個別のドライバーのためにカーネル側をカスタマイズするのはインターフェイスを侵食する越権行為だから、そんなのドライバーのラッパー側でやれ、と言いたくなるのはわかる。 http://mevius.5ch.net/test/read.cgi/tech/1733146370/257
258: デフォルトの名無しさん [sage] 2025/02/08(土) 23:53:09.62 ID:YOrLPiSI >>257 それは君の理解が間違っている 今回はRust製の各デバイスドライバが独自のCバインディングを持つ不便な状況を改善するためのパッチだ つまりカーネルのC側に手を入れるパッチではなくC側は同じままで変更は一切ない 今回の件は該当部分dma_alloc_coherent()のC⇔Rustの抽象ラッパーのコードを含めるパッチだけだ それさえメインテナーに拒否されたため大問題になっている http://mevius.5ch.net/test/read.cgi/tech/1733146370/258
259: デフォルトの名無しさん [sage] 2025/02/08(土) 23:57:46.16 ID:dA8HOTum デバドラはRustで書くのが普通になってきているから そういう共通ラッパーという形のRustインターフェイスが色々と欲しいのよね でもそれはいずれカーネル自体のRust化へ繋がる道になるから強く反対してるのよ http://mevius.5ch.net/test/read.cgi/tech/1733146370/259
260: デフォルトの名無しさん [sage] 2025/02/09(日) 00:59:41.26 ID:LgxLklST 普通に考えたら異種の言語が混ざるとデバッグと開発の障害でしかないからどこかで境目は必要 http://mevius.5ch.net/test/read.cgi/tech/1733146370/260
261: デフォルトの名無しさん [sage] 2025/02/09(日) 06:01:46.16 ID:2Eyl255N >>258 メンテナーがRust用コードのメンテナンスを拒否したということじゃないの？ Rust for Linuxでサポートするような話じゃないんかね。 http://mevius.5ch.net/test/read.cgi/tech/1733146370/261
262: デフォルトの名無しさん [sage] 2025/02/09(日) 06:47:59.48 ID:2n/Om2yv >>260 異種の言語を混ぜる話なんか誰もしていない 今回の事件のパッチも異種の言語を混ぜることなくCのAPIはそのままで その上にRustの層を作る話 In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings. http://mevius.5ch.net/test/read.cgi/tech/1733146370/262
263: デフォルトの名無しさん [sage] 2025/02/09(日) 08:50:09.78 ID:lISaYUpW 最終的にRust側のメンテナが切れてSNSで晒したりしたのは良くなかったけど 技術的にはC側に迷惑かからないように十分配慮して、出てきた懸念も全て潰したにも関わらず 「とにかくRustに関わりたくないから却下」だったからまぁ切れるのも分かる http://mevius.5ch.net/test/read.cgi/tech/1733146370/263
264: デフォルトの名無しさん [sage] 2025/02/09(日) 09:09:11.56 ID:2Eyl255N >>263 そのコードはcで使えるの？ 使えるならともかく、Rust専用ならメンテナーが「そんなののメンテナンスで負担増えるのは嫌だからRustドライバー側でやってくれ」というのもわかる。 Rust for Linuxはこういうのの受け皿にならんのかしらん？ http://mevius.5ch.net/test/read.cgi/tech/1733146370/264
265: デフォルトの名無しさん [sage] 2025/02/09(日) 09:24:37.62 ID:lISaYUpW >>264 受け皿も何もそもそもRust for Linuxでやってる話だし 完全にRustドライバー側でやるからCには影響しないって言ってるわけ 具体的にメンテナンスの負担が増える理由を挙げてくれれば対応策も考えられるけど 「とにかくお前らを邪魔するためなら何でもする」って言ってるからどうしようもない http://mevius.5ch.net/test/read.cgi/tech/1733146370/265
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 123 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.004s