Bun Rustの書き換え: 「コードベースが基本的なMiriチェックに失敗し、安全なRustで未定義動作を許可する」

2026年5月16日原文(github.com)

概要

Rustプログラムで 未定義動作 発生
from_raw_parts によるダングリング参照
Box の解放後にメモリアクセス
問題箇所： PathString::slice
安全なコード設計の重要性

Rustにおける未定義動作と危険なパターン

from_raw_parts は生ポインタからスライスを生成
Box::new で確保したメモリを drop で解放
解放後のポインタを使い続けると ダングリング参照 発生
これはRustでも 未定義動作 （Undefined Behavior, UB）に該当
UBが発生すると、予測不能な動作やクラッシュ、データ破損の危険

問題の具体的なコードパターン

main 関数内でBoxの所有権を持つ変数を生成
その参照やポインタを PathString::init に渡す
drop でBoxのメモリを解放
解放後に init.slice() で元のメモリへアクセス
これにより dangling pointer （ダングリングポインタ）が生じる

安全なRustコード設計のポイント

所有権 と ライフタイム を明確に管理
メモリ解放後のポインタや参照の使用禁止
生ポインタ操作や unsafe ブロックは最小限に留める
from_raw_parts の利用は、メモリの有効期間が保証されている場合のみ
&[u8] や String など安全な型でデータ管理

修正案と推奨パターン

Box や Vec など、所有権とライフタイムが自動管理される型を活用
構造体に &[u8] を保持する場合、元データの所有権またはライフタイムも合わせて管理
どうしても生ポインタを使う必要がある場合は、 drop やスコープに注意

例： PathString にBox自体を持たせる設計に変更

例:

struct PathString(Box<[u8]>);
impl PathString {
  fn slice(&self) -> &[u8] { &self.0 }
}

Rustで安全なコードを書くための心得

未定義動作 を防ぐため、所有権とライフタイムの正しい理解
unsafe の使用は最小限、かつ十分な検証と解説コメントを添付
コンパイラやClippyの警告を無視しない
コードレビューやペアプログラミングで安全性を確保
Rustの 安全性設計思想 を守ることが品質向上への近道

まとめ

Rustは 安全性 が大きな特徴
しかし unsafe や生ポインタ乱用で危険なバグ発生
所有権 と ライフタイム を守ることが最重要
安全なRust設計を心がけることが、バグや未定義動作の防止につながる

Hackerたちの意見

注意やメディアについての考え方が大きく変わった本があるんだ。内容はあんまり良くないけど、ここで重要なことを指摘してる。派手な発表（ここでは、bunがメモリ安全なRustで数週間で書き直された）と、訂正の影響力には大きな非対称性があるんだよね。訂正は、古い記事の脚注に過ぎないことが多いし（ここではGHの問題）、この非対称性はマーケティングやPRのプロたちにしっかり理解されてて、積極的に利用されてる。

└

マーケティングやPRだけじゃなくて、メディアも知ってるよ。デタラメを流して後で訂正することで、元の記事や見出しを覚えている人が多いから、影響が残るってことを。

└

これって「嘘は真実が靴を履く前に世界の半分を回ることができる」っていう言葉に関連してる概念なのかな？

└

派手な発表（ここでは、bunがメモリ安全なRustで数週間で書き直された）彼らは「メモリ安全」って主張してたの？この話題に関する議論では、彼らの雰囲気のあるコードベースが監査されていないunsafeブロックでパンパンになってるって指摘するコメントが何十もあったし、Rustを理解してないだけじゃなくて、そもそもプログラミング言語を理解する必要があるって考えに激怒してる人たちが軽くレビューしてるみたいだ。

└

うーん、今回の一般的な雰囲気を考えると、コードに対する批判を見つけては大きく取り上げようとする人が多い気がする。今のところ、ほとんどが浅い印象だけどね（大規模なLLM支援のポートを統合するのは、確かに、えっと、_大胆_な動きだとは言えるけど、実際の結果については、他の進行中のポートより悪いとは思えないし、見つかった問題についてはかなり騒がれているね）。

└

逆の問題を指摘すると思ってたんだけどね。「大々的な発表」がないのは、ポートがまだ進行中だから。完成してないし、リリースもされてない。見かける大々的な発表は、進行中のコードに対するドライブバイダンクの試みと、彼らが完成したとか完璧だと言ったかのようにほのめかす試みだけ。リライトは、スタート地点としてのコード翻訳だったんだ。>「大々的な発表（ここでは、bunが数週間でメモリ安全なrustに書き直された）」と、相対的に小さな訂正の範囲（古い記事の脚注やGHの問題など）。Bunチームは、コードがメモリ安全になったと大々的に発表したことはない。これはスタート地点だって明言してる。すぐに完璧になって、元のZigコードのメモリ問題が全部解決されると思ってる人は、Bunチームが言ったことじゃなくて、自分が想像した発表と争ってるだけだよ。誰かこのコードを元のコードベースに戻して、メモリ問題が存在するか確認した？

こういうエラーは予想通りだったよ。書き直しに対する問題とは思わないしね。彼らは、安定性が必要な人のためにZigの安定版を残してるし、最終的にはエラーも修正されるだろう。

└

こういうエラーは完全に避けられたはずだよ。Rustのエコシステムには、こういうエラーを検出するための有名なツールがあるし、ツールはunsafeブロックのミスによる全てのUBを検出できるわけじゃないけど、使うのは良いプラクティスとされてる。

このBunの書き直し、なんかマーケティングのスタントみたいに感じる。

└

やっと誰かがこのポイントを理解してくれた。

└

ただの過大評価で、がっかりってこと？

└

無限トークンに何ドル使ったか神のみぞ知るけど、リライトをする * 「Claude CodeがBunチームに100万行以上のZigをRustに書き換えさせた」って大騒ぎして、ブログ記事を書く、VCたちはよだれを垂らす * 基本的なチェックが失敗 * Mythosにコードベースをボロボロにさせて、さらに神のみぞ知るくらいお金を使う * 別のブログ記事を書く * 詐欺師たちと頭の悪い連中が拍手して「妄想的な反AIの群れ」に対抗する * VCたちはさらに興奮する拍手、拍手、拍手。これが金を稼ぐ方法だ、みんな。ところで、今すぐソフトウェアエンジニアを排除する必要がある。

Hacker Newsで議論の続きを見る

ハクソク