注目★★★★★Lobsters
メモリ安全性は「明確な境界」があってこそ、Fil-C と Zig の落とし穴
30秒で把握
- 1Fil-C のメモリ安全定義は「悪用不可能な侵害防止」に限定、バッファオーバーライト許容
- 2著者が提唱する実用的定義：明確な警告表示なしにルール違反が起きるコードは「安全」と呼べない
- 3Python CFI や Rust unsafe extern「C」など明示的マーク有言語は安全と評価可能
要約
Fil-C と Zig が検討する「メモリ安全」は、実は Rust のそれとは定義が異なり、バッファオーバーフローを許容する穴がある。Fil-C は「悪用不可能なメモリ侵害」のみを防ぐため、チェック済みバッファサイズ内の予測不可能なオーバーライトは検知されない。著者は「メモリ安全」を「直感的で、ルールが明確に表示されている」コードの状態と定義し、ルールが不可視・複雑なら「安全」と呼ぶ価値はないと主張する。
あなたへの影響
Zig や新しい C 方言を検討する開発チームは、脆弱性対策のチェックリストとして「サイレント脆弱性 (ルール違反が明示的に警告されないケース) が存在しないか」を評価基準に加えるべき。
推奨：メモリ安全性の定義は技術的な厳密さより、開発者が実装時に安全性を失う箇所を **一目で判断できるかどうか** が実務では優先される。