議論はないけど、先週のフロントページに載ってたやつ（31ポイント） https://news.ycombinator.com/item?id=45655519

前の議論: 2025 SafepointsとFil-C（87ポイント、1ヶ月前、コメント44件） https://news.ycombinator.com/item?id=45258029

2025 Filの信じられないガーベジコレクター（603ポイント、2ヶ月前、コメント281件） https://news.ycombinator.com/item?id=45133938

2024 Fil-Cマニフェスト: ゴミが入れば、安全なメモリが出る（13ポイント、コメント17件） https://news.ycombinator.com/item?id=39449500

何回も投稿されてるけど、最後に確認したときはx86だけだったよ。

フィルCか、同じアイデアの別の実装が必要だと思う。Cで書かれたソフトウェアはたくさんあって、それを動かす方法がないと、その知的遺産にアクセスできなくなっちゃうからね。でも、広範なセキュリティの脆弱性があるから、信頼できない入力を扱うソフトウェア、例えばウェブブラウジングやメールのためのCコンパイルに従来の「YOLO」アプローチを使うのは良くないよね。ピズロは、必要なポインターチェックを驚くほど安く実現する方法を見つけたみたいで、もっと勉強したら理解できるといいなと思ってる。（まだ混乱してるのは、InvisiCapsがmemcpyとどう関わるかってところ。）tialaramexは、CプログラマーがフィルCに興奮するとは期待しない方がいいって指摘してる。tialaramexが言ってるポイントは「DWIM」、つまりランダムなメモリにアクセスして定数時間で実行することなんだけど、ほとんどのCプログラマーは4倍のパフォーマンス低下を受け入れたくないと思う。結局、遅い言語を使いたいなら、Cでコードを書いてないだろうしね。でも、興味を探す場所としてはそれは間違ってると思う。フィルCのターゲットはCプログラムのユーザーであって、Cプログラムの作者じゃないから。私たちは、すでに動いているコードベースを安全に使い続けられる利点が欲しいんだ。すべてをRustやTypeScriptに書き直すコストを払わずにね。そして、多くの人にとって、そのパフォーマンス低下は許容できるものかもしれない。

Fil-CをNix用にパッケージングしているところだよ。それに、Fil-CをツールチェーンとしてNixに統合して、Fil-Cを使ってどんなNixパッケージでもビルドできるようにしてるんだ。 https://github.com/mbrock/filnix ちゃんと動いてるよ。tmuxやnethack、coreutils、Perl、Tcl、Lua、SQLite、他にもいろいろビルドできる。バイナリキャッシュは https://filc.cachix.org にあるから、Clangフォークのビルドを40分待たなくて済むよ。 64ビットのLinuxコンピュータでフレークを使ったNixがあれば、今すぐに「nix run github:mbrock/filnix#nethack」を実行できるよ！

ちょっと関連するけど、安全なC++の提案が続かないみたいだね。 https://news.ycombinator.com/item?id=45234460

要約すると：通常のケースで4倍遅くなる。このアプローチのパフォーマンスオーバーヘッドのせいで、ほとんどのプログラムが約4倍遅くなる。

Cとメモリ安全性を読むたびに、Golangを思い出すんだ。特にユーザースペースでは。

すごいプロジェクトだね。いくつか質問があったけど、自分なりに答えを見つけたと思う（pizlonator、間違ってたら訂正してね）：

1. 誤ったアドレスからの読み書きを防ぐにはどうすればいいの？ 答え：アライメントがずれたポインタの読み書きはトラップされるから、これは単純に許可されてないよ。
2. ポインタを通じてポインタを保存するのはどう実装されてるの？（例えば *(char **)p = s の場合）ランタイムは *p が「フライト」か「ヒープ」かをチェックする必要があるの？ 答え：いいえ。アドレスが取られたフライト（つまりローカル）ポインタは、隣接する2つのワードとして実装されるわけじゃなくて、コールフレームはヒープオブジェクトと同じオブジェクトレイアウトで割り当てられるよ。フライトポインタはその「intval」で、ペアの「lower」は「aux」割り当ての同じオフセットにある（おそらくフレームの一部としても割り当てられてる？）。
3. リターン後の使用エラーはどう防ぐの？ローカルポインタをグローバル変数に保存してからリターンしたら、後で新しい関数を呼んで元のフレームを上書きしたら、誤った lower を取得することにならない？ 答え：いいえ。コールフレームはGCによって割り当てられるから、通常のCスタックとは違うよ。グローバル参照がコールフレームを生かしておくことになるんだ。それに続くプログラムは、絶対に動かないはずなのに、実際には動く。 ~すごい~ 信じられない:

#include <stdio.h>
char *bottles[100];
__attribute__((noinline)) void beer(int count) {
    char buf[64];
    sprintf(buf, "%d bottles of beer on the wall", count);
    bottles[count] = buf;
}
int main(void) {
    for (int i=99; i >= 0; i--)
        puts(bottles[i]);
}

すごい努力だけど、全体のアイデアには少し欠陥があると思う。スピードが必要なら、このC実装は使えないよ。何倍も遅いからね。スピードが重要じゃないなら、メモリ安全な言語を使えばいいじゃん？両方が重要なら、Rustを使えばいいのに。Fil-Cを使ってCで書かれた既存のソフトウェアを再コンパイルするのもあまり良いアイデアじゃないよ。少なくともFil-Cの使用で見つかったバグを修正するために何らかの変更が必要になるだろうし。バグが修正された後も、なぜFil-Cを使い続けるの？