Rustから「extern "fil-c"」を：C言語の安全性を手に入れる新FFI
I want extern "fil-C"
RustのC FFIはメモリ安全性をコンパイル時に保証する一方、unsafe境界を越えたCライブラリは信頼に頼る。Fil-CはC/C++を再コンパイルし、ケイパビリティとランタイムチェック、並行GCでメモリ安全性を実現する。著者はFil-C ABIを話すRust FFIを提案。スカラー値やコピー文字列、不透明ハンドルに限定し、安全なRustラッパーを生成。C依存関係全体をFil-Cでコンパイルし、unsafe Cへの逃げ道をなくす。共有メモリは将来の課題。filnixはFil-CをNixクロスコンパイルプラットフォームとして提供し、100以上のパッケージを移植。ZigもFil-Cに触発されたABIを検討中。Rustは高速パス、Cは安全な互換パスとなり、書き換えの動機になる。
「100%安全」とは、サポートされる境界全体でメモリ安全であることを意味し、ロジックバグやデッドロック、悪いAPIがないことを意味するものではない。
HNでの議論
39- andai
なぜfil-CはCとABI互換ではないのですか？
どうやらこれは意図的なものだそうです。その理由は、安全でないCをfil-Cプログラムで使えるようにしたくないからだとのこと。それはもっともです。
しかし、なぜfil-CプログラムがRust（あるいはC）から使われるのを防ぐ必要があるのでしょうか？
私はコンパイラについてあまり詳しくありませんが、一方を許可すればもう一方も許可できるのではないかと思います。つまり、fil-CをCとABI互換にすること（呼び出しやすくするため）と、そこからCを呼び出すことを許可しないことの両立は不可能だということです。
- pornel
Mozillaが本番環境でレガシーなCコーデックに使っている解決策があります：
これはFil-Cの精密なASAN/Valgrindとしての役割の代わりにはなりませんが、Cライブラリを呼び出しても呼び出し側のメモリを自由に汚染させたくない場合には非常にうまく機能します。
- Panzerschrek
extern "fil-C"はRustコードやそれに類するものとは互換性がありません。各アロケーションにメタデータブロックを付加する必要があるからです。つまり、Rustでメモリブロックが割り当てられ、そのポインタがfil-C関数に渡された場合、正しくアクセスできません。このような言語間・ABI間の呼び出しを可能にする唯一の方法は、Rustコード自体をfil-Cのようにコンパイルすることであり、それにはメモリ消費の倍増、高価なランタイムチェック、GCオーバーヘッドが必要です。
- hechang1997
これをチェックしてみてください：https://github.com/IntegralPilot/rustc_codegen_jvm
これはC/C++をコンパイルすることはできませんが、unsafeな純Rustコードに対するfil-Cの代替として機能します。
- KateLawson
clangの`-fbounds-safety`を使わない理由はありますか？それはABI互換性と段階的な採用を提供します。Fil-Cの作者もそれに取り組んでいました :-)