C言語を救うにはABIを守れ

有名なC言語のジレンマ：私たちは可能な限りマシンに近づきたいと思っているが、マシンが変わるときには何も変えたくない。

しかし、業界は結局互換性の上で成り立っているので、彼らがそうする理由は理解できる。しかし、互換性が壊れたら、ハードウェアベンダーは滅びないだろうか？PLCや他のハードウェアメーカーを見てみると、彼らは現代的なコーディングすら使っていない。彼らはまだ古いコードで動いている。彼らはそれを「安全で認証されたコード」と言うが、実際にはただのレガシーコードだ。

なぜなら、ハードウェアのプログラマーは、研究者を除いて、ソフトウェアのプログラマーに比べて給料がはるかに低く、労働条件も悪いことが多いからだ。ソフトウェア会社では、コード自体が製品である。しかし製造業では、ソフトウェアは何十億ドルもの価値がある機械に付随するコストとして扱われる。設備やセンサーは更新され続け高価になる一方で、すべてを結びつける人々はコスト削減の対象と見なされる。だからハードウェアのプログラマーは一般的に雇用は安定しているが、給料は高くない。そのような状況で、古いやり方に固執する代わりに新しいことを学ぶように求めると、通常は抵抗に遭う。なぜなら、その学習に対して適切な報酬が支払われていないからだ。

何千もの言葉が結局「intmax_tはABI安定ではない」に帰着する。誰が知らなかっただろうか？（誰もが知っていた。）

以前の投稿とコメント：

- 2023-06-10、64ポイント、16コメント：(https://news.ycombinator.com/item?id=36249253)

- 2022-03-13、175ポイント、129コメント：(https://news.ycombinator.com/item?id=30660528)

すべてのC ABI問題の根本原因は共有ライブラリだ。それらはほとんど利益をもたらさずに多くの問題を引き起こす。理想的には、どのアプリケーションもそれらを使うべきではない。すべての依存関係は、同じコンパイラと標準ライブラリでソースからコンパイルされるべきだ。システムライブラリも必要ない。システムコールを直接実行できるはずだ。そのようなアプローチでは、ABIの非互換性は起こり得ない。

共有ライブラリはディスクストレージとRAMの両方のスペースを節約できると言う人もいるかもしれない。しかし、そのような節約はそれほど大きくはなく、場合によってはマイナスになることさえある。ライブラリがリンクインされていれば、未使用の機能を破棄したり、多くのライブラリ関数をインライン化したりすることが可能だからだ。

タイトルに(2022)と付けるべきだろう。何も変わっていないと思うが（私の知る限り）、空は落ちてこなかった。結局のところ、OSとCPUの組み合わせがABIを定義し、コンパイラツールチェーン（言語を問わず）はそれに従うことしかできない（少なくともオペレーティングシステムと通信したいのであれば）。例えば、いつかオペレーティングシステムが安定したRustフレンドリーなABIを実装したら、Cコンパイラはその慣習に適応しなければならなくなるだろう。

> // 提案: 透過的なエイリアス

> _Alias g = f;

定数関数ポインタを定義すればうまくいくと思う。コンパイラがこのポインタを結果の実行ファイルに保存せず、それを介したすべての呼び出しをソース関数への呼び出しに最適化する限り。