私は高水準 (Lisp のような) 言語を C (または、例外が十分に有用であることが判明した場合は C++) でコンパイルすることによって実装する可能性を検討しています。これは、多くのプロジェクトが以前に使用した戦略です。もちろん、これは C コードを生成するものであり、手動で作成するものとは異なり、おそらくいくつかの次元では複雑さを超えています。
最近の C コンパイラは、通常の使用では非常に信頼性が高いですが、異常なストレス下でのエッジ ケースにどのようなバグが潜んでいるのかを知るのは困難です。
これらの事実の偶然が不幸につながるかもしれないと私は思います。
主要なコンパイラ (GCC、Microsoft C++、Clang など) のかなり最近のバージョンで、生成されたコードがエッジ ケースのバグ/制限を超える既知のケースはありますか、またはケースを見つける良い方法はありますか?
これはあなたが探していた答えではないかもしれませんが、数年前、私はシステムの一部が高水準言語で書かれたプロジェクトに取り組みました。このプロジェクトでは、プロセス内にステート マシンを簡単に構築できました。この言語は、その後コンパイルされる C コードを生成しました。このプロジェクトで使用していたコンパイラは gcc でした (バージョン 2.95 前後 - 引用しないでください。確かに 3.0 以前です)。私たちはいくつかのコード生成バグに遭遇しましたが、それは私の記憶によれば、あまり人気のないプロセッサを使用したことによるものでした [どのプロセッサを明らかにすると、プロジェクトについて私がすべきではないことが明らかになる可能性があるので、たとえそれが非常に昔のことであっても、それが何であったかは言わない].
私の近くの同僚は、コード生成のバグの 1 つを調査していました。これは約 20 万行の関数であり、すべての関数は大きな switch ステートメントであり、switch ステートメントの各ケースはそれぞれ約 50 ～ 1000 行です (その中にサブスイッチステートメントのいくつかのレイヤーがあります)。
私の記憶では、コードがクラッシュしていたのは、無効な操作を生成したか、他の何かのために既に占有されているレジスタに何かを格納したためでした。そのため、適切なコードのビットをヒットすると、不正なメモリ アクセスが原因で失敗しました。コードの長いサイズとは何の関係もありませんでした。なぜなら、私の同僚は最終的にコードを約 30 行にまで減らすことができたからです (多くの「これを切り取って、それでもうまくいかないかどうかを確認してみましょう」)。数日後、修正を加えた新しいバージョンのコンパイラがリリースされました。コンパイラ サービス契約に何千ドルも支払う価値があることを知ってうれしい.
ここで私が言いたいのは、最新のコンパイラは大量の大きなコードを許容するということです。「準拠するコンパイラが少なくともサポートしなければならない」という最小制限もあります。たとえば、コンパイラーは関数内で 127 レベルのネストされたステートメント (つまり、127 個の if、switch、while、および do-while の組み合わせ) をサポートする必要があると (記憶から) 確信しています。そして、どこかでの議論 (「コンパイラは 127 レベルのネストされたステートメントをサポートする必要がある」ということです) から、MSVC と GCC の両方がさらに多くのサポートをサポートしていることがわかりました (それを見つけるのをあきらめたほどです... )
C にはあらゆる種類の実装定義の制限があります。明確に定義されていてプログラマーに見えるもの (数値の制限を考えてください) もあれば、そうでないものもあります。ドラフト標準の私のコピーでは、セクション 5.2.4.1 でこれらの制限の下限が詳しく説明されています。
5.2.4 環境制限
翻訳環境と実行環境の両方が、言語トランスレータとライブラリの実装を制約します。以下は、適合する実装における言語関連の環境制限をまとめたものです。ライブラリ関連の制限については、7 節で説明します。
5.2.4.1 翻訳の制限
実装は、次の制限のすべて
のインスタンスを少なくとも 1 つ
含む少なくとも 1 つのプログラムを変換および実行できる必要が
あります。宣言内の算術、構造、共用体、または void 型を変更する宣言子 (任意の組み合わせ)
[...]
18) 実装は、可能な限り固定の翻訳制限を課すことを避けるべきです。
あなたの翻訳者がこれらのいずれかにヒットする可能性があるかどうか、またはあなたが対象としている C コンパイラに問題があるかどうかは、はっきりとは言えませんが、おそらく大丈夫だと思います.
バグに関しては：
Clang - http://llvm.org/bugs/buglist.cgi?bug_status=すべて&product=clang
GCC - http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=すべて&product=gcc
Visual Studio - https ://connect.microsoft.com/VisualStudio/feedback
当たり前のように聞こえるかもしれませんが、実際に知る唯一の方法はテストすることです。自分ですべての作業を行うことができない場合は、少なくとも製品をクロスプラットフォームにして、人々が簡単にテストできるようにしてください! 人々があなたのプロジェクトを気に入れば、通常は喜んでバグレポートやパッチを無料で提出してくれます :)