書いた
“Zigまでもが目を付けた「RustやZigで全部書き直すのではなく、Cコードそのままメモリ安全にする」試みの本家がFil-C。既存の C/C++ソースをほとんど変更なくコンパイル可能、かつメモリ安全になる。実行速度は遅くなる”
魅力は再コンパイルだけで安全になる点だが、依存を全てFil-Cで固める前提と表裏。外部入力を扱うパーサ等、自己完結した信頼境界から適用するのが現実解に見える
C/C++資産をそのままメモリ安全にできるなら理想的だな GC載るから低レイヤ用途で速度影響がどこまで許容されるか
メモリマップ等にも対応出来るのかやや疑問が。
“Fil-C の特徴は「fanatically compatible(狂信的に互換)」を謳っている点です。”
”つまり「メモリ安全のために言語を乗り換えるべきか」という議論には決着が付いておらず、どちら向きに移植するにしても莫大なコストが掛かります。”
『最後のメッセージ「thwarted a futile attempt to violate memory safety(メモリ安全性を侵害しようとする無駄な試みを阻止した)」が良い味を出しています』
それはC言語なのか？と思うけど、「まずは古典的なスタックバッファオーバーフローです」←メモリーオーバーランなのでは。
名前はfilthyのだじゃれかなぁ
“Pizlix”
「標準C言語に統合される未来を持ちえないC言語の方言」を選ぶ人はいるのだろうか？C言語の歴史はコンパイラ独自拡張を標準規格に収束させてきた歴史だ
あくまでユーザーランドだけでカーネルは流石に無理かな
速度が必要でなくてもCで書かれているのにはいいね//速度もマンデルブロはCと互角、ペナルティが一番効きそうなエラトステネスの篩が高々2倍(半分？)、一番驚くのはB-TreeがCと互角ということ//Go速ぇぇぇ
面白いコンセプト。ある意味、言語翻訳みたいなものですかね。Wrapperというか。ちょっと違うかな。
抜け道だらけというか、抜け道しか使ってないようなC/C＋＋実装だと移行に苦労しそう。そんなには見かけないけど。
どんなにAIが優秀でも巨大な遺産を書き直すのは大変すぎる。
そんなこと可能なんだ
いわゆるリアルタイムセーフなコードを書いていると「リアルタイムだから速いはず」と勘違いされることがよくあるけど（実際にはアトミック操作などを伴うので遅い）、GC任せにできるほうが高速なのもよくある話
https://cr.yp.to/2025/fil-c.html djb先生がライブラリをfil-cビルドしたものに差し替えて動かす実験やってたりする
今時のC++だとmallocもnewも配列もあまり使わないと思うけど幾らか有利になるんだろうか
メモリ関連の違反でランタイムエラーは安全とは言えないのでは？メモリ周りの脆弱性の防止には役立つかもしれないが、コンパイル時に弾く設計とは比べられない。
丁寧で分かりやすかった。ただコンパイラでメモリ安全じゃないコードを弾くのではなく、実行時にオーバーランを検知してそのまま動作させるのを防ぐというものだから、Rustとの対比はミスリーディングを誘うのでは？
コンパイラと ABI だけでメモリ安全を実現 InvisiCaps FUGC
GCつきのPurify／Zigのポインタ文法を全部ゴミ箱に叩き捨てる存在なのでは、という気もしたが、Zig文法には手を付けないでZigから呼び出すCコードの話か
Rust に書き直さなくても C 言語をメモリ安全にできる Fil-C を試した
書いた
“Zigまでもが目を付けた「RustやZigで全部書き直すのではなく、Cコードそのままメモリ安全にする」試みの本家がFil-C。既存の C/C++ソースをほとんど変更なくコンパイル可能、かつメモリ安全になる。実行速度は遅くなる”
魅力は再コンパイルだけで安全になる点だが、依存を全てFil-Cで固める前提と表裏。外部入力を扱うパーサ等、自己完結した信頼境界から適用するのが現実解に見える
C/C++資産をそのままメモリ安全にできるなら理想的だな GC載るから低レイヤ用途で速度影響がどこまで許容されるか
メモリマップ等にも対応出来るのかやや疑問が。
“Fil-C の特徴は「fanatically compatible(狂信的に互換)」を謳っている点です。”
”つまり「メモリ安全のために言語を乗り換えるべきか」という議論には決着が付いておらず、どちら向きに移植するにしても莫大なコストが掛かります。”
『最後のメッセージ「thwarted a futile attempt to violate memory safety(メモリ安全性を侵害しようとする無駄な試みを阻止した)」が良い味を出しています』
それはC言語なのか？と思うけど、「まずは古典的なスタックバッファオーバーフローです」←メモリーオーバーランなのでは。
名前はfilthyのだじゃれかなぁ
“Pizlix”
「標準C言語に統合される未来を持ちえないC言語の方言」を選ぶ人はいるのだろうか？C言語の歴史はコンパイラ独自拡張を標準規格に収束させてきた歴史だ
あくまでユーザーランドだけでカーネルは流石に無理かな
速度が必要でなくてもCで書かれているのにはいいね//速度もマンデルブロはCと互角、ペナルティが一番効きそうなエラトステネスの篩が高々2倍(半分？)、一番驚くのはB-TreeがCと互角ということ//Go速ぇぇぇ
面白いコンセプト。ある意味、言語翻訳みたいなものですかね。Wrapperというか。ちょっと違うかな。
抜け道だらけというか、抜け道しか使ってないようなC/C＋＋実装だと移行に苦労しそう。そんなには見かけないけど。
どんなにAIが優秀でも巨大な遺産を書き直すのは大変すぎる。
そんなこと可能なんだ
いわゆるリアルタイムセーフなコードを書いていると「リアルタイムだから速いはず」と勘違いされることがよくあるけど（実際にはアトミック操作などを伴うので遅い）、GC任せにできるほうが高速なのもよくある話
https://cr.yp.to/2025/fil-c.html djb先生がライブラリをfil-cビルドしたものに差し替えて動かす実験やってたりする
今時のC++だとmallocもnewも配列もあまり使わないと思うけど幾らか有利になるんだろうか
メモリ関連の違反でランタイムエラーは安全とは言えないのでは？メモリ周りの脆弱性の防止には役立つかもしれないが、コンパイル時に弾く設計とは比べられない。
丁寧で分かりやすかった。ただコンパイラでメモリ安全じゃないコードを弾くのではなく、実行時にオーバーランを検知してそのまま動作させるのを防ぐというものだから、Rustとの対比はミスリーディングを誘うのでは？
コンパイラと ABI だけでメモリ安全を実現 InvisiCaps FUGC
GCつきのPurify／Zigのポインタ文法を全部ゴミ箱に叩き捨てる存在なのでは、という気もしたが、Zig文法には手を付けないでZigから呼び出すCコードの話か