「実際の」コンピュータプログラムの計算の硬さ

ライスの定理により、Webブラウザー、ワープロ、またはオペレーティングシステムのバグをキャッチするプログラムを作成できないと言われているのをよく耳にします。チューリング完全言語の意味的プロパティはすべて決定不可能です。

ただし、これがオペレーティングシステムなどの実際のプログラムにどの程度当てはまるかはわかりません。これらのタイプのプログラムには、チューリング完全性の完全な強さが必要ですか？これらのアプリケーションを記述できる、より単純な計算モデル（PRなど）はありますか？もしそうなら、これはどの程度プログラムの正確さの決定可能性を可能にしますか？

あなたは間違いなくバグをキャッチするプログラムを書くことができます-それを正確に行うプログラムを書く人々の大規模で活発なコミュニティがあります。ただし、ライスの定理が妨げているのは、健全で完全なバグキャッチャーを作成することです（つまり、特定のクラスのすべてのバグを誤検出なしにキャッチする）。

とはいえ、計算モデルに対する単純な制限は、実際にはプログラム分析の実用性を向上させるのにあまり役立ちません。その理由は、whileループを回すことで、「ほぼ同じこと」を行うプログラムを取得できるためです。

while P do 
   C

大きな反復定数を持つforループに：

for i = 0 to BIGNUM do 
  if P then 
    C
  else
    break

このプログラムは、プリミティブな再帰の完全な強度さえも必要としません（forループは巨大なネストされたif-then-elseステートメントにマクロ展開できるため）。しかし、ほとんどの実際的なケースでは、以前と同じように動作します。これは理論的に決定可能性に役立つことに注意してください-プログラムは完全なので、プログラムを実行して何が起こるかを確認することで質問に答えることができます。これは私たちが実際に望んでいることではありません。つまり、プログラムを実行するよりも速く回答を得ることです。実際のプログラムロジックのエラーが原因でバグが発生するため、導入された人工終了は実際のプログラム分析には役立ちません。それはまったく触れなかった。

$\epsilon_0$

オペレーティングシステムなどの実際のプログラムの正確性について質問したので、seL4プロジェクト（ジャーナル、pdf、 会議）に興味があるかもしれません。

NICTAチームは、Haskellの抽象的な仕様に従って実装されたCの8700行と600行のアセンブラーの第3世代マイクロカーネルを採用しました。彼らは、実装が仕様に厳密に従っていることを（Isabelle / HOLで）正式にマシンチェックした証明を提供しました。したがって、彼らのプログラムにバグがないことを証明します。

したがって、停止の問題と同様に、一般に解決することはできませんが、特定のインスタンスでは解決することができます。この場合、任意のCコードにバグがないことを証明することはできませんが、seL4マイクロカーネルの場合は可能です。

あなたが尋ねる質問は実際にはかなり異なります。

ただし、これがオペレーティングシステムなどの実際のプログラムにどの程度当てはまるかはわかりません。これらのタイプのプログラムには、チューリング完全性の完全な強さが必要ですか？

計算のモデルがチューリング完全であるために非常に少ししかかかりません。たとえば、カウンターを備えたさまざまなモデルは、チューリングマシンをシミュレートできます。ソフトウェアが任意に操作できる3つ以上のカウンターを必要とする場合は、チューリング完全言語を使用しています。マシンの整数は事前に制限されていますが、ヒープに割り当てられたデータ構造は通常は制限されていません。ソフトウェアにリスト、ツリー、その他の動的に割り当てられたデータが必要な場合は、チューリング完全言語を使用しています。

これらのアプリケーションを記述できる、より単純な計算モデル（PRなど）はありますか？もしそうなら、これはどの程度プログラムの正確さの決定可能性を可能にしますか？

ソフトウェアの任意のプロパティをチェックしたくないことを認識することが重要です。非常に具体的で狭いプロパティ（バッファーオーバーフロー、ヌルポインター逆参照、無限ループなど）をチェックすると、ソフトウェアの品質と使いやすさが大幅に向上します。理論的には、そのような問題はまだ決定できません。実際には、特定のプロパティに焦点を当てることで、問題を解決するためにしばしば利用できるプログラムの構造を見つけることができます。

特に、元の質問を次のように変更できます。

非チューリング完全モデルで効率的に分析できるソフトウェアの抽象化はありますか？

抽象化は、元のソフトウェアの動作と、場合によっては多くの追加動作を含むモデルです。チューリング完全ではなく、分析できるワンカウンターマシンやプッシュダウンシステムなどのモデルがあります。自動化ツールを使用したプログラム検証の標準的なアプローチは、そのようなモデルで抽象化を構築し、それをアルゴリズムでチェックすることです。

ハードウェアやソフトウェアの洗練された特性を気にするアプリケーションがあります。ハードウェア企業はチップに算術アルゴリズムを正しく実装することを望んでおり、自動車および航空電子工学企業は認定された正しいソフトウェアを求めています。それが重要な場合は、（訓練された）人間を使用する方がよいでしょう。