JP2002515996A - シミュレートされたプログラムの実行エラーの検出方法および装置 - Google Patents

Abstract

(57)【要約】 プログラムステートメントの実行をシミュレートすることによってコンピュータ・プログラム中のエラーを検出するコンピュータ・プログラム・エラー検出システムである。内部フォーマット構造は、コンピュータ・プログラムによって規定される全ての関数のリストと共に検索される。内部フォーマット構造を分析し、全ての関数呼出しおよび関数呼出しの順序付けを決定する。発見された関数呼出しに対応する外部動作モデルは、検索され、モデル・テーブルに記憶される。１つまたは複数の制御フロー・パスは、コンピュータ・プログラムを介してトラバースされる。トラバースされる各パスについて、構造メモリ・モデルが維持され、制御フロー・パスに沿ったステートメントの実行のシミュレートの結果を表す。ステートメントは、オペレーションの組込みモデルを実行することによってシミュレートされる。関数呼出しは、呼び出された関数に対応する外部動作モデルを実行することによってエミュレートされる。外部動作モデルを実行することにより、構造モデル・メモリが更新され、呼び出された関数の実行を反映する。自動モデル化のために、メモリ・モデルの操作を記述する情報をログする。構造メモリ・モデル中の無効条件が検出され、報告される。各パスの分析の後で、自動モデル化のためにログした情報を操作し、そのパスについてのアウトカムを構築する。個別のパスの分析が完了した後で、様々なアウトカムを処理し、重複を除去し、分析中のコンピュータ・プログラムを表す外部動作モデルを生成する。

Description

【発明の詳細な説明】 シミュレートされたプログラムの実行エラーの検出方法および装置マイクロフィッシュの付録の相互参照 付録Ａは、本開示の一部であり、合計で２１４６個のフレームを有する２２枚 のマイクロフィッシュ・シートからなるマイクロフィッシュの付録である。マイ クロフィッシュの付録Ａは、本発明の一実施態様におけるコンピュータ・プログ ラムおよび関連データのリストである。この実施形態については以下でより完全 に説明する。 本特許文書の開示の一部には、著作権保護を受ける内容が含まれる。著作権所 有者は、特許商標庁の特許ファイルに記録された本特許文書または本特許開示を 正確に複製することには異議を唱えないが、それ以外の場合にはすべての著作権 を留保する。発明の背景 発明の分野 本発明は、コンピュータ・プログラムの分析に関し、詳細には、構造メモリ・ モデルに対してコンピュータ・プログラムをシミュレートされた実行の効果を分 析することによってコンピュータ・プログラムのプログラミング・エラーを検出 することに関する。背景 コンピュータ・プログラムを開発する際には、完成したコンピュータ・プログ ラムの正しさを保証することに多大な努力が払われる。コンピュータ・プログラ ムの目的は、指定された入出力関数をインプリメントすることである。コンピュ ータ・プログラムの正しさとは、プログラムの仕様、設計、インプリメントにお いてエラーが生じない程度である。コンピュータ・プログラムのエラーを検出す る最も一般的な２つの方法は、コンパイル時検査および実行時検査である。 コンパイル時検査とは、形態、構造、または内容に基づいてコンピュータ・プ ログラムを評価するプロセスである。コンパイル時検査は、プログラムが実行さ れる前に確立できる特性を試験する。「構文検査」は、コンパイル時検査の一形 態であり、言語に関して定義された構造規則または文法規則との整合を検証する 。たとえば、周知のＣコンピュータ言語で書かれたコンピュータ・プログラムで は、文Ｂ＋Ｃ＝Ａを使用した場合、正しい形式はＡ＝Ｂ＋Ｃであるためにエラー が生じる。構文検査は、Ｒｉｃｈａｒｄ ＣｏｎｗａｙおよびＤａｖｉｄ Ｇｒ ｉｅｓ著「Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｐｒｏｇｒａｍｍｉｎｇ」 （Ｗｉｎｔｈｒｏｐ Ｐｕｂｌｉｓｈｅｒｓ，Ｉｎｃ．、１９７９年）に詳しく 記載されている。 「データ・フロー分析」は、他の種類のコンパイル時検査であり、コンピュー タ・プログラム内でデータ転送、使用、変換が実行されるシーケンスを分析して プログラミング・エラーを検出する。データ・フロー分析には、制御フロー情報 を使用することが含まれる。「制御フロー」は、コンピュータ・プログラムを実 行する際に文が実行されるシーケンスである。制御フローは、「制御フロー・パ ス」、または単に「コード・パス」とも呼ばれる。データ・フロー分析は、代入 を行う前に変数を使用することや、、２回連続して変数に代入することや、使用 されることのない変数に値を代入することなどのエラーを検出することができる 。 コンパイル時検査モジュールの最大の欠点は、このような方法ではコンピュー タ・プログラム実行の結果が考慮されないために生じる。コンパイル時検査は、 プログラム実行の動的効果を考慮せずに判定できることに限られる。たとえば、 カリフォルニア州マウンテンビューのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社から 市販されているＳＰＡＲＣｗｏｒｋｓ^TM３．０．１．１のプログラミング環境で 使用できるｌｉｎｔコンパイル時チェッカは、コンピュータ・コードによる動的 制御フローにかかわらずにコンピュータ・コードを分析する。この欠点のために 、ｌｉｎｔは、使用中の値を初期設定される前に報告する。したがって、実際に は、報告される値は使用中の値とは異なる。 コンパイル時検査によって生成されるエラー・メッセージは通常、内容が不十 分であるか、あるいは過剰である。コンピュータ・プログラムの特定の関数は、 ある資源が有効である場合、その資源を検査の前に使用することができる。この 関数の外部で資源の有効性が検査されない場合、プログラム終了エラーの可能性 が報告されないため、データ構造が破壊され、場合によっては貴重なデータが失 われる恐れがある。しかし、この関数の前に資源の有効性を検査した場合、エラ ーが報告されると、この関数の分析が擬エラーで混乱し、大規模なプログラムで はコンピュータ・プログラムの分析が無用になる恐れがある。 コンパイル時分析方法で報告される他の種類の擬エラーは、制御フローが進行 できない命令の「明らかな」エラーである。文が実行されるシーケンスは多くの 場合、特定の変数に関連する特定の値に依存する。コンパイル時検査方法は一般 に、特定のコード・パスが実行されるかどうか、あるいはプログラム制御フロー がどんな特定の環境の下でコード・パスを流れるかを判定できないので、文は常 に実行されるものと仮定する。 実行時検査は、他の主要な種類のプログラミング・エラー検出方法であり、コ ンピュータ・プログラムを実行中の動作に基づいて評価するプロセスである。実 行時検査では、既知の１組の入力を用いてコンピュータ・プログラムを実行し、 プログラム結果を予期される結果と比較して検証する。この１組の試験入力、実 行条件、予期される結果を「テスト・ケース」と呼ぶ。多くの場合、エラーを見 つけるのを助けるために、それぞれの異なる点での選択された変数の値を示すプ リントアウト（トレース）が作成される。 概念は簡単であるが、実行時検査の有用性は、コンピュータ・プログラムの複 雑さによって制限される。テスト・ケースを構成し、作成し、実行するには多大 な労力が必要である。多大な労力を払ったにもかかわらず、実行時検査のエラー 検出関数は、選択された特定の１組の入力によって実行されるコード・パスに限 られる。ほとんどの最も簡単なコンピュータ・プログラムでは一般に、すべての 可能な制御フロー・パスを実行することは実際的ではない。さらに、実行時検査 では、コンピュータ・プログラムが完全であり、実行準備が完了している必要が ある。関数を分析するにはその関数を実行しなければならないので、関数を、完 全なプログラムに組み込むだけでなく試験するには、関数に必要な実行環境を与 えるプログラム・シェルを構築する追加の労力が必要である。 典型的なプログラミング・エラー検出方法の欠点を解消する１つの方法が、「 Ｃｏｍｐｕｔｅｒ Ｐｒｏｃｅｓｓ Ｒｅｓｏｕｒｃｅ Ｍｏｄｅｌｌｉｎｇ Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ」と題する米国特許出願第０８／２ ８９１４８号で本出願人によって提示されている。この出願は、１９９４年８月 １０日に出願され、本出願人に譲渡され、引用によって明示的に本明細書と合体 されている。このプログラミング・エラー検出方法は、プログラム資源の状態に 対するプログラム命令の効果を追跡することによってコンピュータ・プログラム の構成要素を分析する。各資源は、各状態の間のいくつかの状態および遷移によ って表される所定の動作を有する。しかし、状態マシンを維持し使用することは 面倒であるので、コンピュータ・プロセス資源モデリングの能力はスプリアス・ エラーを抑制し、詳細なエラー・メッセージを生成することに限られる。さらに 、方法自体の複雑さのために、この方法を具体化する構造を維持し、かつこの方 法を新しい種類のプログラミング・エラーおよびプログラミング言語に拡張する ことは困難である。 実行されるプログラム命令の動作を考慮し、コンピュータ・プログラム内のほ ぼすべての可能な制御フロー・パスを自動的に考慮し、コンピュータ・プログラ ムの個々の関数を分析することのできるプログラミング・エラー検出方法が必要 である。さらに、呼出し関数を分析する際に被呼関数の動作を考慮するプログラ ミング・エラー検出方法が必要である。必要とされるプログラミング・エラー検 出方法は、維持し、かつ新しいプログラミング言語および異なる種類のエラーに 拡張するのも容易でなければならない。必要とされる方法は、スプリアス・エラ ーを最小限に抑え、詳細なエラー・メッセージを生成することもできるべきであ る。発明の概要 本発明によれば、プログラム文の実行をシミュレートすることによってコンピ ュータ・プログラムの実行時動作を分析するコンピュータ・プログラム・エラー 検出システムが提供される。特に、このシステムを使用して、コンピュータ・シ ステム内の関数のサブセットのみ、あるいはプログラム全体を分析することがで きる。一実施態様では、オブジェクト・ベースの設計方法を使用してシステムの 保全性が高められ、同時に高い拡張性が与えられる。 本発明の一実施態様では、コンピュータ・プログラムがプリプロセッサに入力 される。プリプロセッサには、構成ファイル、ヘッダ・ファイル、コマンド行情 報に含まれる指定された構成オプションも入力される。プリプロセッサは、コン ピュータ・プログラムを内部フォーマット構造（構文構文解析ツリー構造）に変 換する。構文構文解析ツリー構造は、コンピュータ・プログラム内で定義された すべての関数のリストと共に中間ファイルに変換される。この中間ファイル、構 成オプション、コマンド行情報、外部動作モデルは分析エンジンに変換される。 分析エンジン処理ではまず、構成オプションが受け入れられる。構成オプショ ンは、分析エンジンによって実行される分析を制御する。制御構成オプションが 決定されると、中間ファイルからコンピュータ・プログラムの内部フォーマット 構造が取り込まれる。分析エンジンは、やはり中間ファイルから、コンピュータ ・プログラムによって定義されたすべての関数を識別する。コンピュータ・プロ グラムの内部フォーマット構造が分析され、すべての関数呼出しが識別される。 関数分析のスケジューリングは識別された関数呼出しの順序によって制御される 。本発明の他の実施態様では、内部フォーマット構造の代わりにコンピュータ・ プログラムの異なる表現を使用することができる。たとえば、コンピュータ・プ ログラムを表すソース・コードを使用することができる。 分析エンジンは、関数を分析する前に、識別された被呼関数に対応するすでに 構築されている外部動作モデルを見つけて取り込む。収集された外部動作モデル は、モデル・テーブル・エントリによって表される。各モデル・テーブル・エン トリは、モデル・テーブルとして収集される。被呼関数に関する外部動作モデル が見つからない場合、その関数は、欠落しているモデルによって表される。モデ ル・テーブルは、関数分析中に外部動作モデルを参照することを可能にする。 コンピュータ・プログラムによって定義された各関数の分析はループで実行さ れる。関数分析の開始時には、その関数に対応する内部フォーマット構造がメモ リに読み込まれる。分析エンジンは、最大数のパスに到達するか、あるいは分析 するパスがもはやなくなるまで、関数を通るコード・フロー・パスを通ることに よってこの関数を分析する。パスの最大数は、分析エンジン処理の限界を決定す るために構成オプションを用いて設定される。決定的選択点履歴を使用して制御 フロー・パスが選択される。いくつかの異なる制御フロー・パスを通る関数のシ ミュレートされた実行は、ＣＰＨツリーによってモデル化される。制御フロー・ パスは未処理の選択点を含むことができる。これは、制御フロー・パス内に処理 できない条件文または述語があることを意味する。ＣＰＨツリー内のノードを使 用して、未処理の各選択点が表される。未処理の選択点の分解能をシミュレート するように、ノードのエッジがランダムに選択される。ＣＰＨツリー内でパスが 選択された後、このパスが分析される。エッジをランダムに選択すると、制御フ ロー・パス内での文の効果を表す構造メモリ・モデルを更新することによって記 憶されるプログラム変数に関する意味が生じる。 選択したすべてのパスが分析された後、分析中の関数の外部動作モデルが収集 される。分析中の関数がもはや必要なくなると、この関数の内部フォーマット構 造がメモリから解放される。最後に、オートモデラがすべての個々のパス結果を 走査し、無関係の動作を削除し、二重の結果を削除する。オートモデラは次いで 、残りの結果をパッケージして、分析中の関数の外部動作モデルを生成する。 特定の制御フロー・パスを分析するには、制御フロー・パスに沿って各文をシ ミュレートする必要がある。分析エンジンは、パス分析の開始時に、分析中の関 数に関してのみ指定された構成オプションがあるかどうかを検査する。現在の関 数の処理は、検出される構成オプションの影響を受ける。分析エンジンは、分析 される各コード・パスごとに、新しい構造メモリ・モデルを構築する。この構造 メモリ・モデルを使用して、制御フロー・パスに沿って各文の実行の効果がシミ ュレートされる。モデル化されたすべてのメモリ位置を追跡する「チャンク・テ ーブル」と呼ばれるテーブルが設けられる。分析される各コード・パスごとに、 コンピュータ・プログラムで使用される変数名をモデル化メモリ内の位置に関連 付ける記号テーブルが作成される。 パス内の第１の分を処理する前に、関数の返却値に関するモデル化メモリ位置 が作成され、この位置が記号テーブルに挿入される。モデル化メモリ位置は、モ デル化中のメモリのアドレス可能な各ユニットあたり１つの記憶値からなる。４ バイト・ポインタをモデル化する場合、モデル化メモリ位置は４つの記憶値を含 む（１バイトあたり１つの値−最低アドレス可能ユニット）。記憶値は記憶値セ ットとして収集される。チャンク・テーブルは、すべての記憶値セットを追跡す ることによってメモリ・モデルを管理する。 メモリ・モデル内に返却値が配置されると、パスに沿って各文が処理される。 各文が処理された後、いくつかの異なるコード・パスの間の結果の比較が容易に なるように記号テーブルが順序付けされる。パス処理では、リーク検出も実行さ れ、各モデル化メモリ位置が探索され、メモリにおいて、割り付けられているに もかかわらず関数が終了した後にどの記号も指し示さない部分があるかどうかが 判定される。検出されたリークについては適切なエラー・メッセージが生成され る。パス処理では最後に、メモリ・モデル内のオートモデラ走査構造が、関数の 各外部動作モデルに対して実行された試験および各外部動作モデルに加えられた 変更を判定する。この情報は、パスに関する結果として要約される。 特定の文の分析では、文がコンピュータ・メモリに与える効果を反映するよう にメモリ・モデルを操作する必要がある。分析エンジンは、文処理の開始時に、 分析中の文に関してのみ指定された構成オプションがあるかどうかを検査する。 現在の文の処理は、検出される構成オプションの影響を受ける。各文は、処理の ために適切な文ユニットに分配される。文の各種類ごとに異なる文ユニットがあ る。一般に、文ユニットは、文中の式を評価し、適切な処理制御結果を再生する ことによって、プログラム文の実行をシミュレートする。 式のオペランドを表すようにモデル化メモリ位置を作成し、式の演算子をオペ ランドに適用する効果をシミュレートするようにメモリ・モデルを更新すること によって、式が評価される。メモリ・モデルの操作を表す情報が、後でオートモ デラによって検査できるようにログされる。演算子を適用する効果のシミュレー ションは演算ユニットによって実行される。演算ユニットは、関数を表すのに使 用される外部動作モデルと同様な組込みモデルを実行することによって演算をシ ミュレートする。 文が関数呼出しである場合、被呼関数に対応する外部動作モデルが実行され、 この関数呼出しの効果がエミュレートされる。対応する外部動作モデルが存在し ない場合、被呼関数が正常にリターンしたという仮定の下にメモリ・モデルが更 新される。被呼関数に関してオートモデラによって生成された外部動作モデルを 使用して、呼出し関数を分析する際に被呼関数をエミュレートすることができる 。 メモリ・モデルで無効な条件が検出された場合、エラー・メッセージが生成さ れる。エラー・メッセージの報告は、構成オプションによって制御される。構成 オプションは、ある無効な条件のみを報告することを可能にするか、あるいはあ る無効な条件の報告を抑制する。さらに、分析エンジンは二重のエラー・メッセ ージを報告しない。 本発明は、以下の詳細な説明と図面に鑑みてより完全に理解されよう。図面の簡単な説明 第１図は、本発明の一実施形態の入出力のブロック図である。 第２図は、第１図に示した本発明の１つの動作環境のブロック図である。 第３図は、第２図の分析器の内部構造のより詳細なブロック図である。 第４図は、第３図のプリプロセッサのより詳細なブロック図である。 第５図は、Ｃプログラミング言語文の例と対応する構文構文解析ツリーの図で ある。 第６図は、第３図の分析エンジンのより詳細なブロック図である。 第７図は、第６図の関数ごと制御ブロックの機能図のブロック図である。 第８図は、第３図の分析エンジンによって実行される処理を表すブロック図で ある。 第９図は、本発明の一実施形態で使用されるモデル・テーブル・エントリの図 である。 第１０図は、第３図の分析エンジンによる処理の開始時に存在する関数呼出し 順序付けおよび外部動作関数モデル・インベントリの例の図である。 第１１図は、第８図の分析関数ブロックによって実行される処理を表すブロッ ク図である。 第１２図は、第１１図の分析パス・ブロックによって実行される処理を表すブ ロック図である。 第１３図は、本発明の一実施形態で使用される記号テーブル・エントリの図で ある。 第１４ａ図は、記号テーブル内の２つのポインタと、第１２図の順序記号テー ブル・ブロックで使用されるモデル化メモリへのそのリンクの高次表現である。 第１４ｂ図は、第１２図の順序記号テーブル・ブロックで使用される記号テー ブルに第１４ａ図とは逆の順序で配置された第１４ａ図からの２つのポインタ（ およびモデル化メモリへのそのリンク）の高次表現である。 第１５図は、本発明のメモリ作成ユニットの一実施形態によって実行される処 理を表すブロック図である。 第１６図は、第１５図のメモリ作成ユニットによって使用される原点コンテキ スト構造の図である。 第１７図は、第１５図のメモリ作成ユニットによって使用されるチャンク・デ ータ構造の図である。 第１８図は、第１５図のメモリ作成ユニットによって使用される記憶値ブロッ クの図である。 第１９図は、第１５図のメモリ作成ユニットによって使用される記憶資源ブロ ックの図である。 第２０図は、第１５図のメモリ作成ユニットによって作成される各データ構造 の間のリンクの高次表現である。 第２１図は、第１１図の初期設定関数ごとデータ構造ブロックによって使用さ れる実行コンテキストブロックの図である。 第２２図は、第１２図のパス・ブロックに沿ってプログラム文で実行される処 理を表すブロック図である。 第２３図は、本発明のブロック・ユニットの一実施形態の論理流れ図である。 第２４図は、本発明の式ユニットの一実施形態の論理流れ図である。 第２５ａ図は、第２４図のプロセス演算アクション２４２４で実行される処理 の一部を表す論理流れ図である。 第２５ｂ図は、第２４図の演算処理アクション２４２４で実行される処理の、 第２５ａ図から始まった説明を完了する論理流れ図である。 第２６図は、第２５ｂ図の演算評価アクション２５３８によって使用される引 数情報ブロックの図である。 第２７図は、本発明の演算ユニットの一実施形態の論理流れ図である。 第２８図は、本発明のｉｆ−ｅｌｓｅユニットの一実施形態の論理流れ図であ る。 第２９図は、本発明のループ実行ユニットの一実施形態の論理流れ図である。 第３０ａ図は、本発明の切換えユニットの一実施形態の一部の論理流れ図であ る。 第３０ｂ図は、切換えユニットの第３０ａ図から始まった説明を完了する論理 流れ図である。 第３１図は、本発明の変数初期設定ユニットの一実施形態の論理流れ図である 。 第３２図は、本発明のリターン・ユニットの一実施形態の論理流れ図である。 第３３図は、本発明のＣＰＨ条件選択ユニットの一実施形態の論理流れ図であ る。 第３４図は、本発明の一実施形態で使用されるメモリ・タイプ情報ブロックの 図である。 第３５図は、本発明の一実施形態で使用される取込み値ブロックの図である。 第３６図は、本発明の一実施形態で使用される述語ブロックの図である。 第３７図は、本発明のエラー生成ユニットの一実施形態の論理流れ図である。好ましい実施形態の詳細な説明 本発明の原則によれば、コンピュータ・プログラムの実行をシミュレートし、 プログラミング・エラーを検出する方法および装置が提供される。特に、本発明 によれば、新規のエラー検出方法は、コンピュータ・プログラムのソース・コー ドを仮想マシン上の演算のシーケンスにマップする。仮想イメージ、すなわち、 分析中のコンピュータ・プログラムによって使用されるメモリの詳細な構造モデ ル（「メモリ・モデル」と呼ぶこともある）は、仮想マシンの状態を表す。コン ピュータ・プログラム中の各変数は、メモリ・モデル内の固有の位置に関連付け される。各位置は値を含む。各値は、一意に識別され、変数またはその他のプロ グラム資源の特定の瞬間を表す。実行可能なプログラム命令は、仮想マシンの命 令に変換される。仮想マシンは、メモリ・モデルに含まれる値に命令の動作モデ ルを適用することによって動作する。モデルを適用すると、不正な演算、無効な 値、リーク、その他の種類のエラーが検出される。 コンピュータ・プログラムを分析するには、いくつかの異なるコード・パスを 通る複数の反復が必要である。個々のコード・パスを通る間、未処理の選択点が 処理される。「選択点」とは、条件または述語の値に基づいて、２組以上のプロ グラム文のうち１つが、実行されるプログラム文として選択されるコンピュータ ・プログラム内の点である。プログラムの変数および資源の部分的な知識のみを 用いて分析を行うと、条件値または述語値が求められず、選択点が未処理になる 可能性がある。 コード・パスに沿った関数呼出しは、関数の外部動作モデルを実行することに よって分析される。この外部動作モデルは、対応する関数が入力されたときに真 でなければならないものと、対応する関数が終了するときに真になるものを反映 する。コンピュータ・プログラムの複数回の反復によって得られた情報は、分析 中のプログラムの外部動作モデルを形成するように抽象化される。 以下の説明では、本発明をより完全に理解していただくために、言語構文、プ ログラム・インタフェース、サンプル・データなど多数の特定の詳細について述 べる。しかし、当業者には、これらの特定の詳細なしに本発明を実施できること が明らかになろう。いくつかの場合には、本発明を不必要にわかりにくくしない ように周知のデータ・フォーマットおよびデータ構造については詳しく説明しな い。関数レベルの分析 通常、コンピュータ・プログラムは、すでに開発されている構成要素と新たに 書かれたコードを組み合わせることによって開発される。本明細書では、「コー ド」は、ソース・コード、すなわち、人間が理解できる形式のコンピュータ命令 および／またはオブジェクト・コード、すなわち、コンピュータが理解できる形 式のコンピュータ命令を指す。コンピュータ・プログラムの構成要素は、１つま たは複数の指定されたタスクを実行するコードの部分である。コンピュータ上で コンピュータ・プログラムを実行するときは、ソース・コードが機械コードに変 換され、プログラムがロード・モジュールとしてメモリにロードされる。ロード ・モジュールの作成とプログラムの実行についての詳細は、Ａｒｔｈｕｒ Ｇｉ ｌｌ著「Ｍａｃｈｉｎｅ ａｎｄ Ａｓｓｅｍｂ１ｙ Ｌａｎｇｕａｇｅ Ｐｒ ｏｇｒａｍｍｉｎｇ ｏｆ ｔｈｅ ＰＤＰ−１１」（Ｐｒｅｎｔｉｃｅ−Ｈａ ｌｌ，Ｉｎｃ．、１９７８年）を参照されたい。 コンピュータ・プログラムは任意の数のコンピュータ言語で書くことができる 。従来型のコンピュータ言語、すなわち被呼手続き言語では、コンピュータが所 与のシーケンス内で実行しなければならない特定の１組の命令をプログラマが記 述する。命令とは、プログラミング言語の文であり、コンピュータによって実行 される演算と、関連するオペランドのアドレスおよび値を指定する。たとえば、 命令Ａ＝Ｂ＋１で、「Ｂ」および「１」はオペランドであり、「＋」は加算演算 を指定するために使用される演算子である。一般に、文は実行すべき動作を指定 する。手続きコンピュータ言語の例には、Ｃ、Ａｄａ、Ｐａｓｃａｌ、Ｆｏｒｔ ｒａｎ、ＣＯＢＯＬ、ＰＬ／１がある。 Ｃ＋＋などいくつかの手続き言語はオブジェクト指向である。オブジェクト指 向プログラミング言語は、オブジェクト、すなわち関数および関連するデータの 概念的なグループ分けを維持する。オブジェクトは、「クラス」と呼ばれる構成 要素に構成される。コンピュータ画面上に表示され、コンピュータ・プログラム を作成するためにコンピュータ・プログラマによってリンクされるグラフィカル 画像として命令が表現されるため、いくつかのコンピュータ言語はグラフィック ス・ベースである。いくつかのコンピュータ言語は、マサチューセッツ州Ｃａｍ ｂｒｉｄｇｅのＬｏｔｕｓ Ｄｅｖｅｌｏｐｍｅｎｔ Ｃｏｒｐｏｒａｔｉｏｎ から市販されているＬｏｔｕｓ １−２−３ Ｓｐｒｅａｄｓｈｅｅｔプログラ ム用のＬｏｔｕｓ １−２−３マクロ言語など特定のソフトウェア製品に特有の 言語である。本発明は、メモリが操作される、任意のコンピュータ言語、すなわ ち任意のコンピュータ命令プロトコルに適用することができる。 上記ではソース・コード・コンピュータ命令プロトコルについて説明したが、 本明細書の教示がオブジェクト・コード形式のコンピュータ命令にも同様に適用 できることが理解されよう。本明細書で説明する例示的な実施形態では、分析さ れる特定のコンピュータ言語は周知のＣコンピュータ言語である。 Ｃコンピュータ言語で書かれたコンピュータ・プログラムは通常、いくつかの 関数に分割される。関数は、ゼロ個以上のパラメータを入力として受け付け、特 定の動作を実行し、多くて１つの戻し項目を出力として生成する。パラメータお よび戻し項目は、メモリに記憶されるデータ構造である。関数は構成要素でも、 あるいは構成要素の一部でもよい。本明細書で説明する例示的な実施形態では、 コンピュータ・プログラムの各関数が個別に分析される。コンピュータ・プログラム分析 第１図は、本発明の一実施形態を示す。エラー検出プロセッサ１０２はコンピ ュータ・プログラム１０４を障害インジケータ１０６およびモデル１１８に変え る。障害インジケータ１０６は、コンピュータ・プログラム１０４内の特定のエ ラーを識別し記述する。本発明の一実施形態では、障害インジケータ１０６はエ ラー・メッセージの形をとる。エラー・メッセージについては以下で詳しく説明 する。モデル１１８は、コンピュータ・プログラム１０４内の対応する関数が実 行する入力メモリから出力メモリへのマッピングを定義する。モデル１１８は、 対応する関数の外部可視動作の要約表現であるので外部動作モデルである。コン ピュータ関数のモデル化については以下で詳しく説明する。 エラー検出プロセッサ１０２によるコンピュータ・プログラム１０４の処理は 様々な入力因子の影響を受ける。このような入力因子には、構成ファイル１１０ 、コマンド行情報１０８、ヘッダ・ファイル１１２、モデル１１８が含まれる。 入力因子については以下で詳しく説明する。 第２図は、エラー検出プロセッサ１０２用の１つの典型的な動作環境を示す。 第２図の実施形態では、エラー検出プロセッサ１０２は、中央演算処理装置（Ｃ ＰＵ）２０４で実行されるアナライザ２０２を備える。ＣＰＵ２０４は、記憶さ れているプログラム命令を実行する。アナライザ２０２は、コンピュータ・プロ グラム１０４、構成ファイル１１０、ヘッダ・ファイル１１２と共にメモリ２０ ６に含まれる。メモリ２０６はさらに、メイン・メモリ（図示せず）と二次記憶 域（図示せず）に細分することができる。メイン・メモリはプログラム命令また はデータを保持し、ＣＰＵ２０４からメイン・メモリに直接アドレスすることが できる。二次記憶域は、直接ＣＰＵ２０４の制御を受けることがなく、あるいは ＣＰＵ２０４から直接アドレスすることのできないデータを含む。当業者には、 メイン・メモリ２０６に含まれている情報をメイン・メモリに記憶するか、ある いは二次記憶域に記憶し、必要に応じてＣＰＵ２０４で実行できるようにメイン ・メモリへ転送することができることが認識されよう。 入出力（Ｉ／Ｏ）回路２０８は、データをＣＰＵ２０４へ転送し、ＣＰＵ２０ ４から受け取る責任を負う。ＣＰＵ２０４、メモリ２０６、入出力回路２０８は 、バス２１０と呼ばれる内部データ・チャネルを通して相互接続される。キーボ ード２１２とマウス２１４は２つの一般的な入力装置であり、ＣＰＵ２０４への データおよび命令の入力を助けるように構成される。たとえば、通常、コマンド 行情報１０８は、エラー検出プロセッサ１０２に与えるためにキーボード２１２ を通して入力される。表示装置２１６とプリンタ２１８は２つの一般的な出力装 置であり、ＣＰＵ２０４からのデータの出力を助けるように構成される。第２図 の実施形態では、出力信号、すなわち障害インジケータ１０６はメモリに記憶さ れる。当業者には、表示装置２１６やプリンタ２１８など他の出力装置へこの出 力信号を送ることもできることが認識されよう。 第３図は、アナライザ２０２の機能図である。プリプロセッサ３０２はコンピ ュータ・プログラム１０４を対応する構文構文解析ツリー構造３０４に変換する 。プリプロセッサ３０２は構文構文解析ツリー構造３０４を中間ファイル３０６ に格納する。プリプロセッサ３０２は、中間ファイル３０６にも関数分析リスト ３１０、すなわち、コンピュータ・プログラム１０４に定義されたすべての関数 のリストを格納する。コンピュータ・プログラム１０４に定義されている関数は 、分析エンジン３０８によって分析される関数である。分析エンジン３０８は、 構文構文解析ツリー構造３０４を通してエラーを検出し、障害インジケータ１０ ６を生成する。分析エンジン３０８は、コンピュータ・プログラム１０４の各関 数についてのモデル１１８も生成する。モデル１１８および分析エンジン３０８ の その他の出力については以下で詳しく説明する。 プリプロセッサ３０２の機能図を第４図に示す。プリプロセッサ３０２は構成 ファイル１１０から演算命令を受け取る。構成ファイル１１０は、ユーザがアナ ライザ２０２をカスタマイズすることを可能にする。構成ファイル１１０に含ま れる設定は、コンピュータ・プログラム１０４が分析される環境の特性を決定す る。たとえば、本発明の一実施形態では、構成オプション「ｍａｘｉｍｕｍ＿ｐ ａｔｈｓ」が、各関数について実行される分析の量の限界を設定する。整数オプ ション値は、アナライザ２０２によって分析されるパスの数の限界を指定する。 本発明の一実施形態に関する構成オプションの完全なリストを付録Ｂに示す。 構成ファイル１１０に含まれる構成オプションは構成ファイル・リーダ４０２ によって処理される。構成ファイル・リーダ４０２は、構成ファイル１１０から 構成オプションを読み込み、構成オプションによって示されたようにパーサ４０ ４の演算属性を設定する。パーサ４０４は、コンピュータ・プログラム１０４の 内部中間表現を作成する。パーサ４０４はヘッダ・ファイル１１２を使用してコ ンピュータ・プログラム１０４を変換する。一実施形態では、ヘッダ・ファイル １１２は、「＃ｉｎｃｌｕｄｅ」Ｃプリプロセッサ指令を通してＣプログラムに よって使用することのできる標準ライブラリ関数を含む。ヘッダ・ファイルは従 来技術でよく知られている。ヘッダ・ファイルの詳細な議論については、Ｍａｒ ｋ Ｗｉｌｌｉａｍｓ Ｃｏｍｐａｎｙの「Ａｎｓｉ Ｃ：Ａ Ｌｅｘｉｃａｌ Ｇｕｉｄｅ」（Ｐｒｅｎｔｉｃｅ Ｈａｌｌ １９８８年）を参照されたい。 分析の準備として、パーサ４０４はコンピュータ・プログラム１０４を解析す る。コンピュータ・プログラムを解析すると、コンピュータ・プログラムがより 多くの基本サブユニットに分解され、各サブユニットの間の関係が確立されるこ とによって、プログラムの構文構造が判定される。パーサ４０４は、コンピュー タ・プログラム１０４に現われる文が、ソース言語（Ｃ）仕様によって許容され るパターンで生じるかどうかを検査する。パーサ４０４は、言語仕様に違反する 文について障害インジケータ１０６を生成する。本発明の一実施形態では、障害 インジケータ１０６はエラー・メッセージの形をとる。言語仕様に違反するエラ ーを「構文エラー」と呼ぶ。 また、他のエラー検出のためにさらに重要なこととして、パーサ４０４は、コ ンピュータ・プログラム１０４の基本サブユニットを構文構文解析ツリー構造３ ０４で表す。構文構文解析ツリー構造３０４は構文構文解析ツリーであり、コン ピュータ・プログラム１０４の構文構造を示す。ツリーとは、多数の分岐を含む 階層構造としてグループ化された要素の集合である。ツリーの一番上の要素をル ート・ノードと呼ぶ。末端ノード、すなわち分岐のないノードをリーフ・ノード と呼ぶ。ツリー内の残りのノードは内部ノードである。 構文構文解析ツリーの概念は、例を介して最もよく理解されよう。第５図は、 簡単なＣ文と対応する構文構文解析ツリーを示す。文５０２「ａ＝ｂ＋１」は２ つの式に分解される。一次式は等式であり、「ａ」を二次式によって生成される 値と等しく設定する。一次式の２つのオペランドは「ａ」と二次式である。二次 式は加算演算であり、「ｂ」に１を加える。二次式の２つのオペランドは「ｂ」 と「１」である。文５０２は構文構文解析ツリー５０４によって表される。構文 構文解析ツリー５０４のルート、すなわちルート・ノード５０６は、等式を表す 等式演算子を含む。ルート・ノード５０６の２つの分岐は、等式の２つのオペラ ンドに至る。リーフ・ノード５０８はオペランド「ａ」を含み、内部ノード５１ ０は、加算演算を表す加算演算子を含む。内部ノード５１０の２つの分岐は加算 演算のオペランドに至る。リーフ・ノード５１２は「ｂ」を含み、リーフ・ノー ド５１４は「１」を含む。 パーサを使用して、コンピュータ・プログラムを解析すること、構文エラー用 のエラー・メッセージを生成すること、構文構文解析ツリーを構築することはす べて、従来技術でよく知られている。コンピュータ・プログラムの解析に関する 詳細な議論については、Ａ１ｆｒｅｄ Ｖ．Ａｈｏ、Ｒａｖｉ Ｓｅｔｈｉ、Ｊ ｅｆｆｒｅｙ Ｄ．Ｕｌｌｍａｎ著「Ｃｏｍｐｉｌｅｒｓ：Ｐｒｉｎｃｉｐｌｅ ｓ，Ｔｅｃｈｎｉｑｕｅｓ，ａｎｄ Ｔｏｏｌｓ」（Ａｄｄｉｓｏｎ−Ｗｅｓｌ ｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ、１９８６年）を参照されたい。 プリプロセッサ３０２は、構文構文解析ツリー構造３０４だけでなく、コンピ ュータ・プログラム１０４に定義されたすべての関数のリストも生成する。この リスト、すなわち関数分析リスト３１０は、構文構文解析ツリー構造３０４と共 に中間ファイル３０６に格納される。分析エンジン３０８は関数分析リスト３１ ０にアクセスし、どの関数を分析すべきかを判定する。 第６図は、分析エンジン３０８の機能図である。主制御ブロック６０２は分析 エンジン３０８の主入口点である。メイン制御ブロック６０２は、ユーザによっ て直接、あるいは統合スクリプトまたは構築ツールによって間接的に、コマンド 行から呼び出される。ユーザは、キーボード２１２またはマウス２１４を通して コマンドを直接入力することによってアナライザ２０２を呼び出す。コマンド行 に入力されるキー情報、すなわち、コマンド行情報１０８の一部は（構文構文解 析ツリー構造３０４を含む）中間ファイル３０６のリストであり、分析すべきコ ンピュータ・プログラムに対応する。コマンド行情報１０８は、構成ファイル１ １０の仕様を含むこともできる。主制御ブロック６０２は分析エンジン３０８内 の処理の順序を制御する。 初期設定ブロック６０４は分析エンジン３０８内の第１の処理を実行する。初 期設定ブロック６０４は、（中間ファイル３０６のリストと構成ファイル１１０ の任意選択の仕様とを含む）コマンド行情報１０８とモデル１１８を処理する。 処理が完了すると、制御は主制御ブロック６０２に戻る。 次に、処理は関数ごと制御ブロック６０６によって実行される。１つの構文構 文解析ツリー構造３０４は、１つのコンピュータ・プログラムに対応し、一度に 分析される。各構文構文解析ツリー構造３０４は、内部に複数の関数を表すこと ができる。関数ごと制御ブロック６０６は一度に１つの関数を分析する。関数ご と制御ブロック６０６は構文構文解析ツリー構造３０４をトラバースし、障害イ ンジケータ１０６を生成する。処理は、分析すべき各構文構文解析ツリー構造３ ０４ごとに繰り返される。すべての構文構文解析ツリー構造３０４が分析された 後、制御は主制御ブロック６０２に戻る。 最後の処理は後処理ブロック６０８によって完了される。後処理ブロック６０ ８は、関数ごと制御ブロック６０６によって分析される関数に対応するモデル１ １８を書き出す。モデル１１８は任意の出力媒体に書き出すことができる。通常 、モデル１１８は二次記憶域に書き出され、そこで他のコンピュータ・プログラ ムの分析に使用することができる。後処理ブロック６０８は制御を主制御ブロッ ク ６０２に返し、分析が終了する。 分析エンジン３０８によって実行される処理の大部分は、関数ごと制御ブロッ ク６０６内で行われる。関数ごと制御ブロック６０６の機能図を第７図に示す。 関数ごと制御ブロック６０６は５つのメイン・オブジェクト上に構築される。オ ブジェクトとは、機能および関連するデータの概念的なグループである。オブジ ェクト・ベースの方法を用いて関数ごと制御ブロック６０６を構成することによ って、分析エンジン３０８の拡張性が高まり、分析エンジン３０８を保守するの が容易になる。拡張性が高まるのは、他のオブジェクトに影響を及ぼさずに特定 のオブジェクト内で機能を追加できるからである。オブジェクトどうしは、慎重 に定義されたインタフェースを使用することによって対話する。インタフェース が維持されるかぎり、１つのオブジェクト内の保守が他のオブジェクトに影響を 与えることはない。したがって、分析エンジン３０８全体にわたって大規模な補 正を施す必要がある場合と比べて、分析エンジン３０８を保守し局所補正を実行 するのが容易である。 構文構文解析ツリー・オブジェクト７０２は、構文構文解析ツリー構造３０４ によって表されたコンピュータ・プログラム１０４内の複数のコード・パスをト ラバースする。構文構文解析ツリー・オブジェクト７０２は、コード・パスを進 むにつれて、命令の演算子を対応するオペランドと共に取り込むことによって、 コード・パスに沿って命令を処理する。取り込まれた演算子およびオペランドは 、シミュレーションのために命令オブジェクト７０６に渡される。構文構文解析 ツリー・オブジエクト７０２は、エミュレーションのために関数呼出しも命令オ ブジェクト７０６に渡す。命令実行のシミュレーションと関数呼出しのエミュレ ーションの両方について以下で詳しく説明する。 仮想マシン７０４は、コンピュータ上のコンピュータ・プログラム１０４の実 行および内部表現をシミュレートする。仮想マシン７０４は、命令オブジェクト ７０６、仮想メモリ・オブジェクト７０８、オートモデル・オブジェクト７１０ からなる。命令オブジェクト７０６は、構文構文解析ツリー・オブジェクト７０ ２から渡された演算子を解釈する。さらに、命令オブジェクト７０６は、処理中 の演算子または関数に対応するモデル１１８を実行する。モデル１１８を実行す ることの効果は、メモリ・モデルが適切に修正されることである。メモリ・モデ ルについては以下で詳しく説明する。 仮想イメージ・オブジェクト７０８は仮想イメージ（図示せず）を維持する。 仮想イメージとはコンピュータ・メモリの構造モデル（「メモリ・モデル」）で ある。仮想イメージ・オブジェクト７０８は、メモリ・モデルの位置、コンピュ ータ・プログラム１０４を「実行」する間に各位置にどんな値が記憶されたか、 特定のメモリ・モデル位置でどんな試験が実行されたかを追跡する。仮想イメー ジ・オブジェクト７０８は、メモリ内の値に作用するｖｉｍプリミティブと呼ば れる１組のプリミティブも維持する。コンピュータ・メモリのモデルとｖｉｍプ リミティブについては以下で詳しく説明する。 オートモデル・オブジェクト７１０は、現在分析中の関数のモデル１１８を構 築する責任を負う。関数内の各コード・パスが実行された後、オートモデル・オ ブジェクト７１０は、仮想イメージ・オブジェクト７０８に問合せを行い、関数 によって実行された入出力マッピングに関する情報を得る。オートモデル・オブ ジェクト７１０によって作成されるモデル１１８は、複数のコード・パスを介し て仮想イメージ・オブジェクト７０８から得られた情報を抽象化したモデルであ る。モデル１１８と、それを構築するのに必要な情報については以下で詳しく説 明する。 検出される大部分のプログラミング・エラーは仮想イメージ・オブジェクト７ ０８で見つけられるが、実際の障害インジケータ１０６は障害インジケータ・オ ブジェクト７１２で生成される。障害インジケータ・オブジェクト７１２は、プ ログラミング・エラーを識別する情報を受け取る。本発明の一実施形態では、情 報がアセンブルされ、障害インジケータ１０６はエラー・メッセージの形でユー ザに提示される。エラー・メッセージ処理については以下で詳しく説明する。アナライザの構成 本発明の一実施形態では、アナライザ２０２のいくつかの異なる構成要素を表 すソース・コードは、パッケージと呼ばれるグループにインプリメントされる。 パッケージとは、より大きなコンピュータ・プログラムの論理的に関係するサブ セットであり、コンピュータ・プログラムに対して関連する１組のサービスを行 う。本発明の一実施形態について、表１に、アナライザ２０２を形成するすべて のパッケージをリストする。表１の「使用されるパッケージ」のシーケンスは、「パッケージ」のシーケンス にリストされたパッケージからアクセスされる他のパッケージを示す。パッケー ジは、それがアクセスする他のすべてのパッケージに依存する。したがって、「 使用されるパッケージ」のシーケンスは、パッケージ依存性のリストを示す。依 存性に留意するのは、パッケージが、依存する他のパッケージの誤動作の悪影響 を受ける可能性があるからである。ｂｏｔ：ユーティリティ・パッケージ ｂｏｔ、すなわちユーティリティ・パッケージは、文字列、ファイル、ファイ ル名、メモリ、集合を操作する汎用関数を与える。これらのユーティリティは、 他のパッケージが移植性の問題の影響を受けるのを妨げる。第２図の実施形態で は、ＣＰＵ２０４上でアナライザ２０２が実行される。異なるＣＰＵを使用した 場合、動作環境から与えられる資源が変更されることがある。ｂｏｔパッケージ は、他のすべてのパッケージをこのような変更から保護する。さらに、ｂｏｔパ ッケージ内のユーティリティは、システム資源を使用する必要のあるパッケージ に関する一様な呼出し規約を提供する。頻繁に使用される関数に関する一様な呼 出し規約を有する場合、アナライザ２０２の保全性が高まる。ｂｏｔパッケージ は他のパッケージには依存しない。 表２は、本発明の一実施形態に含まれるｂｏｔパッケージから与えられるユー ティリティを参照したものである。 集合 ｂｏｔ＿ｃｏｌユーティリティは集合をサポートする。集合とは、概念的には 、順序付けされた１組のメンバまたはこれらのメンバの順序付けされたバッグで ある（すなわち、複製を許可する）。メンバはキーとして使用することができ、 その場合、各メンバに何らかの追加のデータを関連付けることができる。 集合は、種類、内容の説明、サイズを有する。種類は、解釈されない整数に過 ぎず、予期される種類を実際の種類と比較するために使用される。したがって、 集合は明示的に入力され、すなわち、各集合は特定のデータ・クラスを予期する 。内容の説明は、集合が何で構成されているか、たとえば、ビット、整数、コピ ーされた文字列などを指定する。集合のサイズは、集合中のメンバの数である。 本発明の一実施形態では、以下の項目の集合がサポートされる。 ・ブール演算 ・指し示された文字列（集合が単に、文字列を指し示すポインタを記憶する場合 ） ・コピーされた文字列（集合が、文字列にメモリを割り付け、この文字列をコピ ーする場合） ・整数 ・ポインタ（集合が、指し示されているものに関する情報を有さない場合） ・バイト（集合が、これらのバイトの構造に関する情報を有さない場合） アナライザ２０２での集合の一般的な使用は以下の通りである。 ・固定サイズ・ビット・アレイ（抑制コード、選択点履歴） ・名前による参照が重要な可変サイズ文字列リスト（構成オプション） ・記号テーブル：可変サイズであり、解釈されないポインタを指数として有する 。 ・チャンクおよび取込み値の固定サイズの記憶値 ・記憶値のアレイの固定サイズ・サブセット ・（オート・パッケージ内の）パスごと外部テーブル ・述語の集合 ・（モデル内の）結果の集合 ・（結果内の）外部動作モデルの集合 ・モデル・テーブル：可変サイズであり、モデル識別子を指数として有する。 ・（ｍｃｉｌによって生成された）関数ポインタの集合 集合は、ｂｏｔ＿ｃｏｌ＿ｃｒｅａｔｅユーティリティを呼び出し初期サイズ および最大サイズを供給することによって作成される。初期サイズはゼロ要素で よく、最大サイズは無制限でよい。本発明の一実施形態は、集合サイズが無制限 であることを示すためにｂｏｔ＿ｃｏｌ＿ｃｒｅａｔｅユーティリティに渡され るＢＯＴ＿ＣＯＬ＿ＮＯ＿ＭＡＸ＿ＳＩＺＥと呼ばれる定数を定義する。固定サ イズ集合は、初期サイズを最大サイズ値と等しく設定することによって作成され る。固定サイズ集合は、最適化されたいくつかの処理系を可能にする。たとえば 、固定サイズ・ブール演算集合はビットとしてインプリメントされる。ｂｏｔ＿ ｃｏｌ＿ｃｏｐｙユーティリティを呼び出して既存の集合をコピーするか、ある いはｂｏｔ＿ｃｏｌ＿ｓｕｂｓｅｔユーティリティを呼び出して既存の集合のサ ブセットを取り出すことによって、集合を作成することもできる。 集合の各メンバはいくつかの関連する生データを有することができる。メンバ に関連する生データを有することは、記号テーブルを集合としてインプリメント する場合に有用である。記号テーブルとは名前の値へのマッピングである。集合 としてインプリメントされた記号テーブルは、名前をメンバとして表し、その値 を関連する生データとして表す。 本発明の一実施形態では、集合はしばしば、アレイをインプリメントするため に使用される。新しいメンバの指数を返すｂｏt＿ｃｏｌ＿ａｄｄ＿ｍｅｍｂｅ ｒユーティリティを使用することによって、アレイにメンバが追加される。ｂｏ ｔ＿ｃｏｌ＿ｇｅｔ＿ｍｅｍｂｅｒユーティリティを呼び出すことによって、特 定の指数にあるメンバがアレイから取り込まれる。ｂｏｔ＿ｃｏｌ＿ｇｅｔ＿ｍ ｅｍｂｅｒ＿ａｎｄ＿ｒａｗユーティリティによってメンバの値とそれに関連す る生データの両方を取り込むことができる。ｂｏｔ＿ｃｏｌ＿ｒｅｐｌａｃｅ＿ ｍｅｍｂｅｒユーティリティを使用することによってアレイのメンバの値が置き 換えられる。 多くの場合、アレイの各メンバを反復する必要がある。アレイの各メンバを通 過することは、通常、ｆｏｒループを使用して行われ、当技術分野で十分に理解 されている。ｂｏｔ＿ｃｏｌ＿ｇｅｔ＿ｎｕｍ＿ｍｅｍｂｅｒｓユーティリティ はアレイのサイズを返し、このユーティリティを使用してｆｏｒループの上限を 確立することができる。前述のように、ｆｏｒループの本体内部では、ｂｏｔｃ ｏｌ＿ｇｅｔ＿ｍｅｍｂｅｒを使用してアレイの各メンバを取り込むことができ る。 本発明の一実施形態では、参照テーブルは通常、集合としてインプリメントさ れる。ｂｏｔ＿ｃｏｌ＿ｌｏｏｋｕｐ＿ｍｅｍｂｅｒユーティリティを使用して 、メンバの指数を特定の値と共に返すことができる。参照テーブルは、入力値と 出力値との間の対応を識別する。参照テーブルは従来の技術で十分に理解されて いる。分析エンジン３０８の詳細な説明 前述のように、分析エンジン３０８は、障害インジケータ１０６およびモデル １１８を生成するためにユーザによってコマンド行から（あるいは自動化ツール によって間接的に）呼び出される。本発明の一実施形態によれば、分析エンジン ３０８の処理はブロック図８００（第８図）で示されている。処理はベース・パ ッケージアクション８０２（以下では「アクション８０２」と呼ぶ）のグローバ ル・データ構造初期設定から始まり、この場合、４つのベース・パッケージによ って必要とされるグローバル・データ構造が初期設定される。４つのベース・パ ッケージとはｂｏｔパッケージ、ｅｒｒパッケージ、ｃｔｘパッケージ、ｃｏｎ ｆパッケージである。アクション８０２は、コンピュータ・プログラム１０４を 処理するために分析エンジン３０８によって必要とされるセットアップを実行す る。 すべてのパッケージは、ｂｏｔパッケージから与えられるユーティリティを使 用する。したがって、ｂｏｔパッケージによって必要とされるグローバル・デー タ構造がまず初期設定される。初期設定の後で、ｂｏｔパッケージ内のユーティ リティを他のパッケージが使用することができる。次に、構成オプションを処理 する際に出会うエラーを処理するためにｅｒｒパッケージを使用できるようにｅ ｒｒパッケージ内のグローバル・データ構造が初期設定される。ｅｒｒパッケー ジ処理の後で、実行コンテキストブロック２１００、すなわちｃｔｘパッケージ によって定義されるグローバル・データ構造が割り付けされクリアされる。ｅｒ ｒパッケージは、エラー・メッセージに挿入されるコンテキスト情報に関して実 行コンテキストブロック２１００を参照する。実行コンテキストブロック２１０ ０については以下で詳しく説明する。実行コンテキストブロック２１００が初期 設定された後、ｃｏｎｆパッケージのグローバル・データ構造が初期設定される 。第８図の実施形態では、ｂｏｔパッケージ、ｅｒｒパッケージ、ｃｔｘパッケ ージ、ｃｏｎｆパッケージのグローバル・データ構造の初期設定はルーチンによ って実行される。マイクロフィッシュの付録Ａの実施形態では、ｂｏｔパッケー ジ、ｅｒｒパッケージ、ｃｔｘパッケージ、ｃｏｎｆパッケージのグローバル・ データ構造を初期設定するルーチンをそれぞれ、ｂｏｔ＿ｂｅｇｉｎ、ｅｒｒ＿ ｂｅｇｉｎ、ｃｔｘ＿ｂｅｇｉｎ、ｃｏｎｆ＿ｂｅｇｉｎと呼ぶ。処理はアクシ ョン８０２からデフォルト構成ファイル処理アクション８０４（以下では「アク ション８０４」と呼ぶ）へ移る。 構成オプションは、分析エンジン３０８によって実行される多くの処理に影響 を与える。したがって、アクション８０２で必要なセットアップが行われると、 アクション８０４で構成オプションが処理される。構成オプションは構成ファイ ル１１０内に記憶される。デフォルト構成ファイル１１０はデフォルト・オプシ ョン設定を含む。デフォルト構成ファイル１１０は分析エンジン３０８用の標準 構成を生成する。 デフォルト構成ファイル１１０はアクション８０４内で処理される。まず、デ フォルト構成ファイルが見つけられる。本発明の一実施形態では、デフォルト構 成ファイルはアナライザ２０２のホーム・ディレクトリに格納される。デフォル ト構成ファイル１１０が見つかった後、分析エンジン３０８にデジタル・オプシ ョン設定がロードされる。デフォルト構成ファイルに含まれるすべてのオプショ ンがロードされるまで、オプション設定が一度に１つずつ読み込まれる。第８図 の実施形態では、デフォルト構成ファイル１１０はルーチンによって処理される 。マイクロフィッシュの付録Ａの実施形態では、ｃｏｎｆ＿ｌｏａｄ＿ｄｅｆａ ｕｌｔｓルーチンによってアクション８０４が実行され、このルーチンはｃｏｎ ｆ＿ｒｅａｄ＿ｆｉｌｅルーチンをすべてのオプションを読み込む。ｃｏｎｆ＿ ｒｅａｄ＿ｆｉｌｅルーチンは、構成ファイル１１０全体にわたって１行ずつ反 復し、ｃｏｎｆ＿ｐａｒｓｅ＿ｏｐｔｉｏｎルーチンを使用して構成ファイルの 各行を解析し、オプションを取り込む。アクション８０４によって実行される関 数は当業者によく知られている。 構成オプションは、分析エンジン３０８によって実行される分析のレベルと、 分析エンジン３０８によって生成される出力の種類および量を制御する。たとえ ば、構成オプションは、処理中のコードで実行されるパスの数と、どんなエラー が報告されるかと、エラーが報告される形式と、あるエラーが報告される場所を 判定することができる。第８図の実施形態については、構成オプションのリスト および各オプションの説明はアペンデッィクスＢに含まれている。 処理は、アクション８０４からユーザ指定構成情報処理アクション８０６（以 下では「アクション８０６」と呼ぶ）に移り、ユーザ指定構成ファイル１１０が 処理される。ユーザは、コマンド行情報１０８内のコマンド行上に構成ファイル １１０を指定することによって分析エンジン３０８内で実行される処理をカスタ マイズするオプションを有する。ユーザ指定構成ファイル１１０に設定された構 成オプションは、デフォルト構成ファイル１１０に設定された対応するオプショ ンに優先する。 本発明の一実施形態では、コマンド行上の「−ｃｏｎｆｉｇ」制御語を使用し てオプションのユーザ指定構成ファイル１１０が識別される。「−ｃｏｎｆｉｇ 」制御語の後に空白が続き、その後にユーザ指定構成ファイル１１０の名前が続 く。たとえば、「−ｃｏｎｆｉｇ ｃｕｓｔｏｍ」は、「ｃｕｓｔｏｍ」と呼ば れるユーザ指定構成ファイル１１０を識別する。 アクション８０６はまず、ユーザがオプションの構成ファイル１１０を指定し たかどうかを判定する。そうでない場合、アクション８０６ではもはや処理は必 要とされない。ユーザ指定構成ファイル１１０が識別された場合、処理はアクシ ョン８０４と同様に継続する。アクション８０６内では、ユーザ指定オプション 設定が分析エンジン３０８にロードされる。このようなユーザ指定オプション設 定は、アクション８０４に設定された対応するデフォルト設定に優先する。ユー ザ指定構成ファイル１１０に含まれるすべてのオプションがロードされるまで、 オプション設定は一度に１つずつ読み込まれる。第８図の実施形態では、ユーザ 指定構成ファイル１１０はルーチンによって処理される。マイクロフィッシュの 付録Ａの実施形態では、アクション８０６はｃｏｎｆ＿ｌｏａｄルーチンによっ て実行され、このルーチンは、ｃｏｎｆ＿ｌｏａｄ＿ｄｅｆａｕｌｔｓルーチン と同様に、ｃｏｎｆ＿ｒｅａｄ＿ｆｉｌｅルーチンを使用してすべてのオプショ ンを読み込む。 アクション８０６は、ユーザによって指定されたコマンド行構成オプションも 処理する。コマンド行情報１０８内のコマンド行上に複数の構成オプションを指 定することができる。本発明の一実施形態では、制御行構成オプション（および その値）の前に「−ｐｒｅｆｉｘ＿ｏｐｔ」制御語が指定される。「−ｐｒｅｆ ｉｘ＿ｏｐｔ」制御語の後で、引用符で囲まれた構成オプションに値が割り当て られる。言い換えれば、コマンド行構成オプション指定は以下の形式を有する。 −ｐｒｅｆｉｘ＿ｏｐｔ“ｏｐｔｉｏｎ ｎａｍｅ＝ｏｐｔｉｏｎ ｖａｌｕ ｅ” たとえば、「ｍａｘｉｍｕｍ＿ｐａｔｈｓ」構成オプションは、以下のものを指 定することによってコマンド行上に設定することができる。 −ｐｒｅｆｉｘ＿ｏｐｔ“ｍａｘｉｍｕｍ＿ｐａｔｈｓ＝３００” 付録Ｂは、本発明の一実施形態についての様々な構成オプションおよび許容され るオプション値を含む。 アクション８０６は、コマンド行構成オプションをコマンド行上のその位置に 対して左から右へ処理する。構成オプションがコマンド行上に指定されたか、そ れとも構成ファイル１１０内に含まれるかにかかわらず、所与のコマンド行構成 オプション指定は、すでに指定されているすべての構成オプションに優先する。 処理はアクション８０６から残余グローバル・データ構造初期設定アクション ８０８（以下では「アクション８０８」と呼ぶ）へ移り、コンピュータ・プログ ラム１０４を分析する準備として残りのパッケージが初期設定される。構成オプ ションをロードした後の、処理を行う方法は知られている。この時点で、処理に 必要とされるグローバル・データ構造が初期設定される。本発明の一実施形態で は、ａｕｔｏパッケージ、ｃｐｈパッケージ、ｅｘｅパッケージ、ｉｎｓパッケ ージ、ｍｃｉｌパッケージ、ｓｙｍパッケージ、ｖｉｍパッケージはすべて、グ ローバル・データ構造を有し、これらの構造を初期設定しなければならない。第 ８図の実施形態では、ルーチンを使用してパッケージ内のグローバル・データ構 造が初期設定される。マイクロフィッシュの付録Ａの実施形態では、「ｐｋｇ＿ ｂｅｇｉｎ」と呼ばれるルーチンによってパッケージ内のグローバル・データ構 造が初期設定される。「ｐｋｇ」はパッケージの名前を表す。たとえば、ａｕｔ ｏパッケージ内のグローバル・データ構造は、「ａｕｔｏ＿ｂｅｇｉｎ」と呼ば れるルーチンによって初期設定される。 処理はアクション８０８から中間ファイル読取りアクション８１０（以下では 「アクション８１０」と呼ぶ）へ移り、コマンド行情報１０８内のコマンド行上 にリストされた中間ファイル３０６が読み取られ、準備処理が実行される。まず 、コマンド行に含まれる中間ファイル３０６のリストが取り込まれる。各中間フ ァイル３０６の内容がメモリに読み込まれる。ユーザは、空白で区切られた複数 の中間ファイル３０６をコマンド行上に指定することができる。 プリプロセッサ３０２は、構築されたあらゆる中間ファイル３０６に関数分析 リスト３１０を挿入する。関数分析リスト３１０は、対応する中間ファイル３０ ６内の分析すべきすべての関数を含む（すなわち、構文構文解析ツリー構造３０ ４によって表されたプログラムによって定義されたすべての関数のリスト）。分 析すべきすべての関数を識別する関数分析マスタ・リストを形成するために、コ マンド行上に指定されたすべての中間ファイル３０６から得たすべての関数分析 リスト３１０の複合リストが作成される。 分析を必要とするすべての関数の名前が判明した後、処理では続いて、すべて の被呼関数の名前が判定される。「被呼関数」は、（通常は一時的に）転送され る実行の制御である関数を示す。関数分析マスタ・リストを巡回することによっ てすべての被呼関数のリストが生成される。分析を必要とする各関数について、 対応する構文構文解析ツリー構造３０４がトラバースされ、呼び出される関数が 調べられる。アクション８１０は、すべての被呼関数の名前と関数呼出しの順序 の両方を判定する。 分析エンジン３０８は、被呼関数の実行をエミュレートする。分析エンジン３ ０８は、対応するモデル１１８を実行できる場合、被呼関数のより確実なエミュ レーションを実行することができる。そうでない場合、分析エンジン３０８は、 通常実行される被呼関数を示すことからなる最低限のエミュレーションを実行す る。 すべての被呼関数の名前を収集した後、これらの関数に関して存在するすべて のモデルを収集することが可能である。アクション８１０内で生成される関数呼 出しの順序によって、分析エンジン３０８は、プログラム全体がより完全に調べ られるように関数分析の順序付けを調整することができる。分析エンジン３０８ はできる限り、関数を分析の他の部分でエミュレートすることが必要になる前に その関数を分析しモデル化する。関数分析の適切な順序は、アクション８１０の 最後に関数呼出し順序付け情報のトポロジカル・ソートを行うことによって決定 される。トポロジカル・ソートによって、順序付けされた関数呼出しのリストが 生成される。関数は、順序付けされた関数呼出しのリストに示された順序で処理 される。トポロジカル・ソートは当技術分野でよく理解されている。 例１は、第１０図に示されており、関数呼出し順序付けの例を示す。第１０図 を参照するとわかるように、関数Ｆ１ １００２は関数Ｆ２ １００４を呼び出 す。関数Ｆ２ １００４は関数Ｆ３ １００６およびＦ４ １００８を呼び出す 。この例では、関数ｆ１ １００２、ｆ２ １００４、ｆ３ １００６は関数分 析マスタ・リスト上にある（すなわち、分析を必要とする）。被呼関数のリスト にはｆ２ １００４、ｆ３ １００４、ｆ４ １００８が含まれる。これらの関 数のうちで、分析の開始時に存在するのは関数ｆ４ １００８のモデル、ｆ４モ デル１０１０だけである。したがって、ｆ４モデル１０１０が実行され、関数ｆ ４ １００８の呼出しがエミュレートされる。関数呼出し順序付けでは、分析の 開始時にどのモデルが存在するかだけでなく、どの関数を最初に分析するかも決 定される。ｆ２ １００４のモデルが構築される前にまずｆ１ １００２を分析 すると、ｆ２ １００４の最低限のエミュレーションが行われる。ｆ２ １００ ４を最初に分析しモデル化した場合は、関数ｆ１ １００２をより詳しく分析す ることができる。同様な理由で、ｆ２ １００４を分析する前にｆ３ １００６ が分析されモデル化される。ｆ３ １００６が分析されモデル化された後、ｆ２ １００４のより完全な分析が可能になり、最終的にｆ１ １００２がより良好 に分析される。 処理はアクション８１０からモデル・テーブル構築アクション８１２（以下で は「アクション８１２」と呼ぶ）へ移り、モデル・テーブルが構築される。モデ ル・テーブルとは、モデル・テーブル・エントリ９００を指し示すポインタの集 合である。各モデル・テーブル・エントリ９００は、被呼関数リスト上の被呼関 数に対応する。モデル・テーブル・エントリ９００を第９図に示す。モデル・テ ーブル・エントリ９００は、「ｆｕｎｃｔｉｏｎ ｎａｍｅ（関数名）」９０２ 、「ｍｏｄｅｌ ｐｏｉｎｔｅｒ（モデル・ポインタ）」９０４、「ｍｏｄｅｌ ｓｏｕｒｃｅ（モデル・ソース）」９０６、「ｏｕｔｐｕｔ ｄｅｓｔｉｎａ ｔ ｉｏｎ（出力宛先）」９０８、「ｎｅｗｅｒ ｍｏｄｅｌ ｉｎｄｅｘ（新しい モデル・インデックス）」９１０、「ｌｏａｄｅｄ ｆｌａｇ（ロード済みフラ グ）」９１２、「ｍｉｓｓｉｎｇ ｆｌａｇ（欠落フラグ）」９１４、「ｒｅｐ ｏｒｔ ｍｉｓｓｉｎｇ ｆｌａｇ（欠落報告フラグ）」９１６、「ａｕｔｏｍ ｏｄｅｌ ｆｌａｇ（オートモデル・フラグ）」９１８、「ｎｅｗｅｒ ｍｏｄ ｅｌ ｆｌａｇ（新しいモデル・フラグ）」９２０、「ｗｒｉｔｔｅｎ ｆｌａ ｇ（書込み済みフラグ）」９２２、「ｒｅｐｌａｃｅ ｆｌａｇ（置換えフラグ ）」９２４、「ｑｕｅｕｅ ｆｏｒ ｗｒｉｔｅ ｆｌａｇ（書込み待ち行列フ ラグ）」９２６の各フィールドを含む。 フィールド「ｆｕｎｃｔｉｏｎ ｎａｍｅ」９０２は、モデル・テーブル・エ ントリ９００に関連付けされた関数の識別子を指定する。フィールド「ｍｏｄｅ ｌ ｐｏｉｎｔｅｒ」９０４は、モデル・テーブル・エントリ９００によって表 されるモデル１１８を指し示す。フィールド「ｍｏｄｅｌ ｓｏｕｒｃｅ」９０ ６は、「ｍｏｄｅｌ ｐｏｉｎｔｅｒ」９０４によって指し示されたモデルがど こから読み取られたかを指定する。フィールド「ｏｕｐｕｔ ｄｅｓｔｉｎａｔ ｉｏｎ」９０８は、「ｍｏｄｅｌ ｐｏｉｎｔｅｒ」９０４によって指し示され たモデルを書きこむファイルを指し示す。フィールド「ｎｅｗｅｒ ｍｏｄｅｌ ｉｎｄｅｘ」９１０は、このモデル・テーブル・エントリ９００が関連付けさ れているのと同じ関数のモデルのより新しいバージョンを指し示すモデル・テー ブル内のエントリのインデックスを指定する。 「ｌｏａｄｅｄ ｆｌａｇ」９１２は、このテーブル・エントリに関してモデ ルがロードされているかどうかを示す。「ｍｉｓｓｉｎｇ ｆｌａｇ」９１４は 、このテーブル・エントリに特殊な「ｍｉｓｓｉｎｇ ｍｏｄｅｌ」が割り当て られているかどうかを示す。「ｒｅｐｏｒｔ ｍｉｓｓｉｎｇ ｆｌａｇ」９１ ６は、このテーブル・エントリに関して「ｍｉｓｓｉｎｇ ｍｏｄｅｌ」メッセ ージが発行されているかどうかを示す。「ａｕｔｏｍｏｄｅｌ ｆｌａｇ」９１ ８は、「ｍｏｄｅｌ ｐｏｉｎｔｅｒ」９０４によって指し示されたモデルが、 現在の分析中にオートモデラによって作成された場合には真である。「ａｕｔｏ ｍｏｄｅｌ ｆｌａｇ」９１８は、モデルが最初に、現在のコンテキストのコン テ キスト外でオートモデラによって作成された場合でも偽である。「ｎｅｗｅｒ ｍｏｄｅｌ ｆｌａｇ」９２０は、このモデル・テーブル・エントリ９００が関 連付けされているのと同じ関数の、オートモデラによって生成されたモデル１１ ８を表すモデル・テーブル・エントリ９００をオートモデラが追加しているかど うかを示す。「ｗｒｉｔｔｅｎ ｆｌａｇ」９２２は、モデルがファイルに書き 出されたかどうかを示す。「ｒｅｐｌａｃｅ ｆｌａｇ」９２４は、「ｍｏｄｅ ｌ ｐｏｉｎｔｅｒ」９０４によって指し示されているモデル１１８をオートモ デラが置き換えているかどうかを示す。最後に、「ｑｕｅｕｅ ｆｏｒ ｗｒｉ ｔｅ ｆｌａｇ」は、分析の終了時にモデルに書き出すべきである場合は真であ る。そうでない場合は偽である。 まず、アクション８１２内で、モデル・テーブルを具体化する集合が作成され る。モデル・テーブルはテーブル・エントリ９００をモデル化する１組のポイン タであるので、ポインタの集合が作成される。モデル・テーブルの集合が作成さ れると、テーブル内にエントリはなくなる。次に、モデル・テーブル内の初期エ ントリが作成される。すなわち、モデル・テーブル・エントリ９００を指し示す メンバがモデル・テーブル集合に追加される。本発明の一実施形態では、モデル ・テーブル集合はルーチンによって構築される。マイクロフィッシュの付録Ａの 実施形態では、ルーチンｉｎｓ＿ｍｔ＿ｒｅａｄがモデル・テーブルの構築を制 御し、ｂｏｔ＿ｃｏｌ＿ｃｒｅａｔｅ＿ｃｏｌｌｅｃｔｉｏｎユーティリティ・ ルーチンを呼び出してモデル・テーブル集合を作成する。 アクション８１２は次に、モデル・テーブルによって指し示された初期モデル ・テーブル・エントリを作成する。アクション８１２は、アクション８１０内で 構築された被呼関数のリスト上の各関数を巡回する。このリスト上の各関数につ いて、モデル・テーブル・エントリ９００が割り付けられ初期設定される。フィ ールド「ｆｕｎｃｔｉｏｎ ｎａｍｅ」９０２は現在の被呼関数の名前に設定さ れる。次いで、モデル・テーブル・エントリ９００は、フィールド「ｍｉｓｓｉ ｎｇ ｆｌａｇ」９１４を真に設定することによって欠落モデルを示すように設 定される。モデル・テーブル集合にメンバを追加することによって、新たに作成 されたモデル・テーブル・エントリを指し示すポインタがモデル・テーブルに挿 入される。また、オートモデラによって生成されたモデル１１８で欠落モデルを 置き換えるべきであることを示すフラグ「ｒｅｐｌａｃｅ ｆｌａｇ」９２４が オンにされる。このように、処理は被呼関数リスト全体にわたって反復される。 したがって、アクション８１２が完了した後、被呼関数リスト上のあらゆる関数 に関するモデル・テーブルによって指し示される１つのモデル・テーブル・エン トリ９００がある。本発明の一実施形態では、モデル・テーブルはルーチンを通 して初期設定される。マイクロフィッシュの付録Ａの実施形態では、ルーチンｍ ｃｉｌ＿ｇｅｔ＿ｎｅｘｔ＿ｍｏｄｅｌ＿ｔｏ＿ｒｅａｄは被呼関数名のリスト 全体にわたって反復され、ルーチンｉｎｓ＿ｍｔ＿ｉｎｓｅｒｔはモデル・テー ブル・エントリ９００を作成し、このエントリを欠落モデルを示すように初期設 定し、ｂｏｔ＿ｃｏｌ＿ａｄｄ＿ｍｅｍｂｅｒユーティリティ・ルーチンはモデ ル・テーブル集合にメンバを追加するために使用される。処理はアクション８１ ２から集合モデル化アクション８１４（以下では「アクション８１４」と呼ぶ） へ移る。 アクション８１４は、モデル・テーブルで参照された各モデル・テーブル・エ ントリ９００に対応するすでに構築されているモデル１１８（すなわち、被呼関 数リスト上のすべての関数のモデル）を収集する。利用可能なモデル１１８を探 索する第１のステップは、モデル・ファイルを探索する位置のリストを構築する ことである。モデル・ファイルとはモデルを含むファイルであり、規約上、ファ イル拡張識別子を区別することによってモデル・ファイルが認識される。たとえ ば、「ｍｏｄ」と「ｍａｒ」は、モデル・ファイルを識別する２つの拡張子であ る。「ｍｏｄ」拡張子は現在のモデル１１８を含むモデル・ファイルを示し、「 ｍａｒ」拡張子は、保存されているモデル１１８を含むモデル・ファイルを示す 。単一のモデル・ファイルに複数のモデル１１８を格納することができる。モデ ル・ファイルは、ファイルにどの関数がモデル化されているかを示すインデック ス情報をファイルの開始位置と終了位置に有することができる。 通常、モデル・ファイルはディレクトリに配置され、ファイルを探索する場所 のリストは１組のディレクトリである。組内の各ディレクトリは、モデル・ファ イルを求めて探索される。適切なファイル拡張子を有するすべてのファイルが処 理される。選択された各ファイルについて、モデル・ファイルが割り付けされ開 かれる。モデル・ファイルを開いた後、インデックスが走査され、ファイル内の モデル１１８のうちで、分析に必要な関数に対応するモデルがあるかどうかが判 定される。これは、モデル・ファイル・インデックス中の関数名を被呼関数リス ト上の名前と比較することによって行われる。名前が一致するたびに、一致した 関数を表すモデル・テーブル・エントリ９００内で「ｌｏａｄｅｄ ｆｌａｇ」 ９１２が真に設定されていないかぎり、対応するモデル１１８が解析されメモリ にコピーされる。コピーされたモデル１１８を指し示すポインタは、フィールド 「ｍｏｄｅｌ ｐｏｉｎｔｅｒ」９０４にある対応するモデル・テーブル・エン トリ９００に入力される。このモデル・テーブル・エントリ９００に関する「ｍ ｉｓｓｉｎｇ ｆｌａｇ」はオフにされる。また、この同じモデル・テーブル・ エントリ９００について、「ｌｏａｄｅｄ ｆｌａｇ」９１２が真に設定され、 「ｒｅｐｌａｃｅ ｆｌａｇ」９２４が偽に設定される。「ｌｏａｄｅｄ ｆｌ ａｇ」９１２が真に設定されたときは、アクション８１４が、モデル・テーブル ・エントリ９００によって表された関数に一致するすべての後続のモデル１１８ を無視すべきであることを意味する。すべての一致が処理されると、選択された モデル・ファイルの処理が完了し、モデル・ファイルが閉じられ割付け解除され る。モデル１１８については以下で詳しく説明する。本発明の一実施形態では、 アクション８１４はあるルーチンによって実行される。マイクロフィッシュの付 録Ａの実施形態では、ルーチンｉｎｓ＿ｍｔ＿ｒｅａｄが、すでに構築されてい るモデル１１８を見つけ、ルーチンｉｎｓ＿ｍｔ＿ｐａｒｓｅがモデル・ファイ ル内のモデルを解析する。 アクション８１４は、ファイルのリスト、すなわち出力モデル・ファイル・リ ストも生成する。このリストは、分析中に構築されたモデル１１８の出力宛先を 指定する。出力モデル・ファイル・リストは、モデル１１８がモデル・テーブル ・エントリ９００に挿入されるときに動的に構築される。モデル１１８がモデル ・テーブル・エントリ９００にリンクされると、出力モデル・ファイル・リスト が検査され、モデル１１８によって表される関数のソース中間ファイル３０６と 同じファイル名と「ｍｏｄ」のファイル拡張子とを有する対応する出力モデル・ ファイルがあるかどうかが調べられる。探している出力モデル・ファイルが見つ からない場合、このファイルは出力モデル・ファイル・リストに追加される。あ る関数を表すように構築されたモデル１１８は、最初にその関数を定義した中間 ファイルに対応する出力モデル・ファイルに格納される。たとえば、中間ファイ ル「ｔｅｓｔ．ｉｌ」が関数ｆ１を含む場合、関数ｆｌを表すように構築された モデル１１８は出力モデル・ファイル「ｔｅｓｔ．ｍｏｄ」に格納される。アク ション８１４がモデル・テーブル・エントリ９００を初期設定すると、フィール ド「ｏｕｔｐｕｔ ｄｅｓｔｉｎａｔｉｏｎ」９０８が、フィールド「ｆｕｎｃ ｔｉｏｎ ｎａｍｅ」９０２で識別された関数を含む中間ファイル３０６に対応 する出力モデル・ファイルの名前を記録するように設定される。モデル・ファイ ルについては以下で詳しく説明する。処理はアクション８１４から関数分析アク ション８１６（以下では「アクション８１６」と呼ぶ）へ移る。 アクション８１６は、関数分析マスタ・リスト上のすべての関数を分析する。 処理の順序は、順序付き関数呼出しリストによって制御される。関数は、順序付 き関数呼出しリスト上の第１の関数から最後の関数まで順次分析される。各関数 について、対応する構文構文解析ツリー構造３０４がメモリに読み込まれる。関 数を分析すると、障害インジケータ１０６（エラーが検出された場合）と、分析 された関数を表すモデル１１８が生成される。関数の分析が完了すると、メモリ に読み込まれた構文構文解析ツリー構造３０４は破棄される。このように、必要 に応じてのみ構文構文解析ツリー構造３０４を記憶することによって、ＣＰＵ２ ０４のメモリ資源が節約される。アクション８１６で実行される関数ごと処理に ついては以下で詳しく説明する。処理は、アクション８１６から出力モデルアク ション８１８（以下では「アクション８１８」と呼ぶ）へ移る。 アクション８１８は、アクション８１６によって作成されたモデル１１８を記 憶する責任を負う。出力モデル・ファイル・リスト内の各出力モデル・ファイル は順次処理される。まず、モデル出力ファイルが作成され、割り付けられ、開か れる。次に、アクション８１８が、モデル・テーブル全体にわたって反復され、 各モデル・テーブル・エントリ９００に問合せを行う。フィールド「ｏｕｔｐｕ t ｄｅｓｔｉｎａｔｉｏｎ」９０８が現在のモデル出力ファイルの名前に等し く、フラグ「ｑｕｅｕｅ ｆｏｒ ｗｒｉｔｅ ｆｌａｇ」９２６が真である場 合、フィールド「ｍｏｄｅｌ ｐｏｉｎｔｅｒ」９０４によって指し示されたモ デル１１８が現在のモデル出力ファイルに格納される。「ｗｒｉｔｔｅｎ ｆｌ ａｇ」９２２は真に設定される。 出力モデル・ファイル・リスト内の最後のファイルに対する処理が完了すると 、制御はグローバル・データ構造除去アクション８２０（以下では「アクション ８２０」と呼ぶ）へ移る。 処理はアクション８２０で終了し、記憶域クリーンナップが行われる。第８図 の実施形態では、あるルーチンを使用して、パッケージ内のグローバル・データ 構造が除去またはクリーンナップされる。マイクロフィッシュの付録Ａの実施形 態では、「ｐｋｇ＿ｅｎｄ」と呼ばれるルーチンを実行することによって、パッ ケージ内のグローバル・データ構造が除去またはクリーンアップされる。「ｐｋ ｇ」はパッケージの名前を表す。たとえば、ｅｒｒパッケージ内のグローバル・ データ構造は、「ｅｒｒ＿ｅｎｄ」と呼ばれるルーチンによってクリーンナップ される。ｂｏｔ、ｅｒｒ、ｃｏｎｆ、ａｕｔｏ、ｃｐｈ、ｃｔｘ、ｅｘｅ、ｉｎ ｓ、ｍｃｉｌ、ｓｙｍ、ｖｉｍの各パッケージには「ｐｋｇ＿ｅｎｄ」ルーチン が実行される。この時点で、コンピュータ・プログラム１０４の処理が完了する 。関数分析 前述のように、関数分析マスタ・リスト上にリストされた関数の分析はアクシ ョン８１６で行われる。（アクション８１０で実行されるトポロジカル・ソート によって作成される）順序付き関数呼出しリストは、関数が分析される順序を制 御する。アクション８１６は、ブロック図１１００（第１１図）に示したように 、順序付き関数呼出しリストを巡回し、リスト上の各関数について関数ごと処理 を実行する。分析中の関数は現在の関数として指定される。関数ごと処理は、関 数ごとデータ構造初期設定アクション１１０２（以下では「アクション１１０２ 」と呼ぶ）から始まる。 アクション１１０２は、関数ごとに使用されるデータ構造を割り付けるか、あ るいは初期設定する。第１１図の実施形態では、あるルーチンを使用することに よって、パッケージ内の関数ごとデータ構造を割り付けるか、あるいは初期設定 する。マイクロフィッシュの付録Ａの実施形態では、「ｐｋｇ＿ｂｅｇｉｎ＿ｆ ｕｎｃｔｉｏｎ」（「ｐｋｇ」はパッケージの名前を表す）と呼ばれるルーチン が、パッケージ内の関数ごとデータ構造を割り付けるか、あるいは初期設定する 。たとえば、ｅｘｅパッケージ内の関数ごとデータ構造は、「ｅｘｅ＿ｂｅｇｉ ｎ＿ｆｕｎｃｔｉｏｎ」と呼ばれるルーチンによって割り付けられる。「ｐｋｇ ＿ｂｅｇｉｎ＿ｆｕｎｃｔｉｏｎ」ルーチンは、ｃｔｘ、ｍｃｉｌ、ｅｒｒ、ｖ ｉｍ、ｓｙｍ、ｉｎｓ、ｃｐｈ、ａｕｔｏ、ｅｘｅのパッケージ順序で呼び出さ れる。 アクション１１０２は、実行コンテキストブロック２１００に情報をポストす る。実行コンテキストブロック２１００を第２１図に示す。実行コンテキストブ ロック２１００には、「ｆｉｌｅｎａｍｅ（ファイル名）」２１０２、「ｆｕｎ ｃｔｉｏｎ ｎａｍｅ（関数名）」２１０４、「ｃｕｒｒｅｎｔ ｆｕｎｃｔｉ ｏｎ（現在の関数）」２１０６、「ｃｕｒｒｅｎｔ ｉｔｅｒａｔｉｏｎ（現在 の反復）」２１０８、「ｃｕｒｒｅｎｔ ｓｔａｔｅｍｅｎｔ（現在の文）」２ １１０、「ｃｕｒｒｅｎｔ ｌｉｎｅ ｎｕｍｂｅｒ（現在の行番号）」２１１ ２、「ｃｕｒｒｅｎｔ ｅｘｐｒｅｓｓｉｏｎ（現在の式）」２１１４、「ｅｍ ｕｌａｔｉｏｎ ｄｅｐｔｈ（エミュレーション深さ）」２１１６、「ｅｍｕｌ ａｔｉｏｎ ｃｏｎｔｅｘｔ ｌｉｓｔ（エミュレーションコンテキストリスト ）」２１１８の各フィールドが含まれる。 フィールド「ｆｉｌｅｎａｍｅ」２１０２は、現在の関数を含むソース・ファ イルを識別する。フィールド「ｆｕｎｃｔｉｏｎ ｎａｍｅ」２１０４は、現在 の関数を識別する。フィールド「ｃｕｒｒｅｎｔ ｆｕｎｃｔｉｏｎ」２１０６ は、現在の関数を一意に識別する、現在処理されている構文構文解析ツリー構造 ３０４内のノードを指し示すポインタである。フィールド「ｃｕｒｒｅｎｔ ｉ ｔｅｒａｔｉｏｎ」２１０８は、分析された現在の関数中のパスの数のカウント を指す。フィールド「ｃｕｒｒｅｎｔ ｓｔａｔｅｍｅｎｔ」２１１０は、現在 分析されている文を識別する、現在処理されている構文構文解析ツリー構造３０ ４内のノードを指し示すポインタである。フィールド「ｃｕｒｒｅｎｔ ｌｉｎ ｅ ｎｕｍｂｅｒ」２１１２は、現在分析されている文を含むフィールド「ｆｉ ｌｅｎａｍｅ」２１０２のソース・ファイル内の行を識別する。フィールド「ｃ ｕｒｒｅｎｔ ｅｘｐｒｅｓｓｉｏｎ」２１１４は、現在分析されている式を識 別する、現在処理されている構文構文解析ツリー構造３０４内のノードを指し示 すポインタである。フィールド「ｅｍｕ１ａｔｉｏｎ ｄｅｐｔｈ」２１１６は 、フィールド「ｆｕｎｃｔｉｏｎ ｎａｍｅ」２１１４内の関数の入れ子にされ た関数呼出しの深さである。フィールド「ｅｍｕｌａｔｉｏｎ ｃｏｎｔｅｘｔ ｌｉｓｔ」２１１８は、入れ子にされた関数呼出しで呼び出される各関数に関 するコンテキスト情報の集合である。関数呼出しが「入れ子にされる」のは、そ の関数呼出しが他の関数呼出しの引数として使用されるか、あるいはそれ自体の 引数の１つとして他の関数呼出しを使用するときである。フィールド「ｅｍｕｌ ａｔｉｏｎ ｄｅｐｔｈ」２１１６および「ｅｍｕｌａｔｉｏｎ ｃｏｎｔｅｘ ｔ ｌｉｓｔ」２１１８が意味を持つのは、現在分析されている式が関数呼出し であるときだけである。 アクション１１０２は、「ｆｉｌｅｎａｍｅ」２１０２、「ｆｕｎｃｔｉｏｎ ｎａｍｅ」２１０４、「ｃｕｒｒｅｎｔ ｆｕｎｃｔｉｏｎ」２１０６を設定 する。本発明の一実施形態では、あるルーチンを使用して、実行コンテキストブ ロック２１００の最初の３つのフィールドが初期設定される。マイクロフィッシ ュの付録Ａの実施形態では、「ｃｔｘ＿ｂｅｇｉｎ＿ｆｕｎｃｔｉｏｎ」と呼ば れるルーチンが実行コンテキストブロック２１００の最初の３つのフィールドを 初期設定する。関数ごとデータ構造が割り付けられるか、あるいは初期設定され 、グローバル・データ構造が関数レベル情報で更新された後、処理は構文構文解 析ツリー構造ロードアクション１１０４へ移る（以下では「アクション１１０４ 」と呼ぶ）。 アクション１１０４は、現在の関数を表す構文構文解析ツリー構造３０４をメ モリに読み込む。処理は、アクション１１０４からパス分析アクション１１０８ （以下では「アクション１１０８」と呼ぶ）へ移る。 アクション１１０８は、現在の関数全体にわたる複数のコード・パスをシミュ レートされた実行を追跡することによって現在の関数を分析する。アクション１ １０８は、最大パス数に達するか（ｍａｘｉｍｕｍ＿ｐａｔｈオプションが設定 されている場合）、あるいはもはや実行するコードがなくなるまで、コード・パ スを実行し続ける。ｍａｘｉｍｕｍ＿ｐａｔｈオプションは、ユーザが、各関数 に対して実行される分析の量の限界を設定することを可能にする。ｍａｘｉｍｕ ｍ＿ｐａｔｈオプションを設定すると、（現在の関数内のいくつかのコード・パ スがトラバースされていない場合でも）分析されるパスの数の上限が設定される 。アクション１１０８は、最初に実行すべきパスを見つけるループを実行し、次 いでこのパスを実行する。 アクション１１０８は、決定的選択点履歴を使用してパスを見つける。関数の 実行は、選択点ノードと選択エッジからなる選択点履歴（ＣＰＨ）ツリーとして モデル化される。ＣＰＨツリーは、第５図に示した構文構文解析ツリーと同様に 構造のツリーである。ＣＰＨツリーのルート・ノードは、現在の関数中の第１の 未処理の選択点であり、リーフ・ノードは関数リターンおよび関数終了である。 前述のように、選択点とは、条件または述語の値に基づいて２組以上の代替プロ グラム文のうちの１組の間で選択が行われるプログラム内の点である。選択点ノ ードは、分析エンジン３０８が、処理するのに十分な情報を有さない選択点に対 応する。選択点ノードは、現在の関数内の未処理の選択点に対応する構文構文解 析ツリー構造３０４内のノードを指し示すポインタを含む。選択エッジは、選択 点のいくつかの異なる可能な処理に対応する。たとえば、相等性に関する試験で は真と偽のどちらかが判定される。選択点ノードは相等性試験に対応する。この 特定の選択点ノードは２つの選択エッジを有する。一方の選択エッジは「真」結 果に対応し、一方は「偽」結果に対応する。 選択点履歴は、各パスが複製可能であるという点で決定性である。コードのい くつかの異なる実行において未処理の各選択点を同様に処理する場合、コード内 の同じパスをたどる。各選択点ノードは、固定数の選択エッジを有する。これは 、未処理の選択点ノードから延びるパスの数が固定されることを意味する。この 数は、実行の前には未知であるが、選択点ノードに関する選択を初めて行うとき に決定される。現在の関数を実行する前にはＣＰＨツリー構造全体が未知である 。ＣＰＨツリーは、現在の関数を分析する間に動的に構築される。 ＣＰＨツリーは、修正幅優先構築方法を使用したプログラム実行中に構築され る。アクション１１０８は「現在レベル」値を維持する。現在レベル値は、ＣＰ Ｈツリーにどの選択点が追加されたかを示す。任意の所与の時間には、現在のレ ベルよりも１つ以上上のレベルであるＣＰＨツリーのすべてのノードが処理され ている。したがって、これらのノードのすべての選択エッジが決定される。 アクション１１０８は、現在のレベルよりも１つ上のレベルであるノードから 出てルート・ノードに戻る未処理の選択エッジを無作為に選択することによって 、新しいパスを選択する。このように、アクション１１０８は、ルート・ノード から始まるパスを決定し、現在のレベルよりも１つ上のレベルの選択されたノー ドまでＣＰＵツリーをトラバースする。現在のレベルよりも１つ上のレベルのノ ードから出る未処理の選択エッジが見つからない場合、現在レベル値が１だけ増 加され、ステップが繰り返される。現在レベル値を増加させることは、分析がＣ ＰＨツリー内で１レベル下に移動したことを意味する。現在レベル値が増加され 、現在のレベルよりも１つ上のレベルのノードから出る未処理の選択エッジが依 然としてない場合、もはやパスを見つけることはできない。本発明の一実施形態 では、あるルーチンによって新しいパスが決定される。マイクロフィッシュの付 録Ａの実施形態では、「ｃｐｈ＿ｐａｔｈ＿ｆｉｎｄ」ルーチンが新しいパスを 決定する。 各パスが決定されるたびに、アクション１１０８はメモリ・モデルを作成し、 コード・パスに沿った命令のメモリ・モデルに対する効果をシミュレートし、コ ード・パス上の関数呼出しをエミュレートし、エラーを検出した時点で障害イン ジケータ１０６を生成し、現在の関数のモデル１１８を構築するのに必要な情報 を収集する。このパスごと処理については以下で詳しく説明する。処理はアクシ ョン１１０８から関数外部動作モデル収集アクション１１１０（以下では「アク ション１１１０」と呼ぶ）へ移る。 アクション１１１０は、将来モデル作成時に使用される現在の関数の外部動作 モデルを収集する。アクション１１１０は、収集した外部動作モデルをグローバ ル変数に変換する。以後の処理時に、モデル作成ルーチンがグローバル変数から このような外部動作モデルを抽出する。関数外部動作モデルとは、関数の外部で 参照することができるか、あるいはいくつかの関数呼出しにわたって持続する値 、すなわち局所静的変数を有する関数内のオブジェクトである。関数外部動作モ デルの最も一般的な２つの例はパラメータと返却値である。現在の関数の外部動 作モデルが記録された後、処理はアクション１１１０から構文構文解析ツリー構 造解放アクション１１１２（以下では「アクション１１１２」と呼ぶ）へ移る。 アクション１１１２は、現在の関数を表す構文構文解析ツリー構造３０４を解 放する。現在の関数を表す構文構文解析ツリー構造３０４を必要なくなった時点 で解放することによって、メモリ資源を効率的に使用することができる。本発明 の一実施形態では、アクション１１１２はあるルーチンによって実行される。マ イクロフィッシュの付録Ａの実施形態では、ルーチン「ｍｃｉｌ＿ｒｅｌｅａｓ ｅ＿ｍｅｍｏｒｙ＿ｒｅｇｉｏｎ」が構文構文解析ツリー構造３０４を解放する 。処理はアクション１１１２から関数ごとデータ構造クリーンナップアクション １１１４（以下では「アクション１１１４」と呼ぶ）へ移る。 関数ごと処理はアクション１１１４で終了し、関数ごとに使用される記憶域が クリーンナップされる。本発明の一実施形態では、ルーチンを使用して、パッケ ージ内の関数ごとデータ構造が解放またはクリーンナップされる。このルーチン は、ｅｘｅ、ａｕｔｏ、ｃｐｈ、ｉｎｓ、ｓｙｍ、ｖｉｍ、ｅｒｒ、ｍｃｉｌ、 ｅｘｅのパッケージ順で呼び出される。特に、それぞれのａｕｔｏパッケージ・ ルーチンは現在の関数のモデル１１８を作成する。オートモデル化については以 下で詳しく説明する。マイクロフィッシュの付録Ａの実施形態では、「ｐｋｇ＿ ｅｎｄ＿ｆｕｎｃｔｉｏｎ」（「ｐｋｇ」はパッケージの名前を表す）というラ ベルの付いたルーチンが、関数ごとに使用される記憶域をクリーンナップまたは 解放する。たとえば、ｖｉｍパッケージ内の関数ごとデータ構造は、「ｖｉｍ＿ ｅｎｄ＿ｆｕｎｃｔｉｏｎ」というラベルの付いたルーチンによって解放される 。「ｐｋｇ＿ｅｎｄ＿ｆｕｎｃｔｉｏｎ」ルーチンは、「ｐｋｇ＿ｂｅｇｉｎ＿ ｆｕｎｃｔｉｏｎ」ルーチンの逆の順序で呼び出される。アクション１１１４が 完了すると、関数ごと処理が終了する。パスの分析 前述のように、アクション１１０８は、複数のシミュレートされた実行のコー ド・パスを追跡することによって現在の関数を分析する。アクション１１０８は 、分析する各パスごとに１回ずつ、現在の関数を表す構文解析ツリー構造３０４ （以下では、「現在の構文解析ツリー構造３０４」と呼ぶ）をトラバースする。 アクション１１０８は、分析する各パスについて、ブロック図１２００（第１２ 図）に示したようにパスごと処理を実行する。分析中のパスは現在のパスとして 指定される。パスごと処理は、プログラム読取りアクション１２０２（以下では 「アクション１２０２」と呼ぶ）から始まる。 アクション１２０２は、現在の関数に関してプラグマが定義されているかどう かを判定する。プラグマとはＩｎｔｒｉｎｓａ指令であり、プラグマの直後の関 数または文の制御を設定する。ユーザは、関数のソース・コードにＩｎｔｒｉｎ ｓａプラグマを埋め込むことによって構成オプションを指定することができる。 関数の直前に配置されたプラグマは、関数全体に適用される。たとえば、以下の プラグマは、主関数のすべての文に適用される。 「抑制（ｓｕｐｐｒｅｓｓ）」構成オプションの詳細は、付録Ｂに記載されてい る。 アクション１２０２は、プラグマを見つけるとまず、プラグマによって指定さ れた構成オプションの現在の設定を保存し、次いでプラグマに指定された値に応 じてこのような構成オプションを設定する。処理はアクション１２０２からパス ごとデータ構造初期設定アクション１２０４（以下では「アクション１２０４」 と呼ぶ）へ移る。 アクション１２０４は、パスごとに使用されるデータ構造を割り付けるか、あ るいは初期設定する。第１２図の実施形態では、あるルーチンを実行することに よって、パッケージ内のパスごとデータ構造が割り付けられるか、あるいは初期 設定される。このようなルーチンは、ｃｔｘ、ｍｃｉｌ、ｅｒｒ、ｖｉｍ、ｓｙ ｍ、ｉｎｓ、ｃｐｈ、ａｕｔｏ、ｅｘｅのパッケージ順で呼び出される。マイク ロフィッシュの付録Ａの実施形態では、アクション１２０４で実行されるルーチ ンには「ｐｋｇ＿ｂｅｇｉｎ＿ｐａｔｈ」（「ｐｋｇ」はパッケージの名前を表 す）というラベルが付けられる。たとえば、ｓｙｍパッケージ内のパスごとデー タ構造は、「ｓｙｍ＿ｂｅｇｉｎ＿ｐａｔｈ」というラベルの付いたルーチンに よって割り付けられる。 チャンク・テーブルは、アクション１２０４によって作成されるパスごとデー タ構造の例である。チャンク・テーブルは、１組のすべてのモデル化メモリを含 み、記憶域管理とリーク検出のために使用される。本発明の一実施形態では、チ ャンク・テーブルは、チャンクを指し示すポインタの集合としてインプリメント される。チャンクとは既知のメモリのモデル化された部分であり、これについて は以下で詳しく説明する。概念的には、追跡されるあらゆるパスは関数の異なる 実行であり、したがって、各実行をサポートするために新しいメモリ・モデルが 作成される。本発明の一実施形態では、チャンク・テーブルはあるルーチンによ って作成される。マイクロフィッシュの付録Ａの実施形態では、「ｖｉｍ＿ｂｅ ｇｉｎ＿ｐａｔｈ」ルーチンがチャンク・テーブルを作成する。 アクション１２０４によって作成される他のパスごとデータ構造は記号テーブ ルである。記号テーブルは、名前（「記号」）を含む構文解析ツリー・ノードを メモリ・モデル内の位置と関連付ける。記号テーブルとは、記号テーブル・エン トリ１３００を指し示すポインタの集合である。各記号テーブル・エントリ１３ ００は、現在の関数で使用される変数に対応する。 記号テーブル・エントリ１３００を第１３図に示す。記号テーブル・エントリ １３００は、「ｐａｒｓｅ ｔｒｅｅ ｐｏｉｎｔｅｒ（構文解析ツリー・ポイ ンタ）」１３０２、「ｓｙｍｂｏｌ ｔｙｐｅ（記号タイプ）」１３０４、「ｍ ｅｍｏｒｙ ｔｙｐｅ（メモリ・タイプ）」１３０６、「ｓｙｍｂｏｌ ｌｏｃ ａｔｉｏｎ（記号位置）」１３０８、「ｓｙｍｂｏｌ ｌｏｃａｔｉｏｎ ｐｏ ｉｎｔｅｒ（記号位置ポインタ）」１３１０、「ｐａｒｅｎｔ ｉｎｄｅｘ（親 インデックス）」１３１２の各フィールドを含む。メモリ・モデル内の位置につ いては以下で詳しく説明する。 フィールド「ｐａｒｓｅ ｔｒｅｅ ｐｏｉｎｔｅｒ」１３０２は、記号テー ブル・エントリ１３００によって表される記号を定義する現在の構文解析ツリー 構造３０４内のノードを指し示す。フィールド「ｓｙｍｂｏｌ ｔｙｐｅ」１３ ０４は、記号テーブル・エントリ１３００によって表される記号の種類を識別す る。本発明の一実施形態では、フィールド「ｓｙｍｂｏｌ ｔｙｐｅ」１３０４ の可能な値は「変数」、「定数」、「ルーチン」、「差」、「返却値」である。 フィールド「ｍｅｍｏｒｙ ｔｙｐｅ」１３０６は、記号テーブル・エントリ１ ３００によって表される記号の値を保持するために使用されるメモリの種類を記 述する。メモリ・タイプについては以下で詳しく説明する。 フィールド「ｓｙｍｂｏｌ ｌｏｃａｔｉｏｎ」１３０８は、記号テーブル・ エントリ１３００によって表される記号の値を記憶するチャンクを指し示すコー ド化ポインタである。コード化ポインタについては以下で詳しく説明する。フィ ールド「ｓｙｍｂｏｌ ｌｏｃａｔｉｏｎ ｐｏｉｎｔｅｒ」１３１０は、「ｓ ｙｍｂｏｌ ｌｏｃａｔｉｏｎ」１３０８によって指し示されるチャンクのコー ド化ポインタを記憶するチャンクのコード化ポインタ（すなわち、記述中の記号 の値を指し示すポインタ）である。フィールド「ｐａｒｅｎｔ ｉｎｄｅｘ」１ ３１２は差のためだけに使用される。差とは、ポインタによって指し示される値 を指す。記号テーブル・エントリが微分値を表すとき、フィールド「ｐａｒｅｎ ｔ ｉｎｄｅｘ」１３１２は、この微分値に到達するために使用されるポインタ の記号テーブル内でのインデックスを保持する。たとえば、記号テーブル・エン トリが^*Ｐ（Ｐによって指し示される値）のエントリである場合、フィールド「 ｐａｒｅｎｔ ｉｎｄｅｘ」１３１２は、ポインタＰの記号テーブル内でのイン デックスを含む。 アクション１２０４は、実行コンテキストブロック２１００に情報をポストす る。アクション１２０６はフィールド「ｃｕｒｒｅｎｔ ｉｔｅｒａｔｉｏｎ」 ２１０８内のカウントを１（このパスの数を示す）だけ更新する。処理は返却値 レイアウトアクション１２０６（以下では「アクション１２０６」と呼ぶ）へ移 る。 アクション１２０６は、現在の関数の返却値用のモデル化メモリをレイアウト する。アクション１２０６はまた、返却値を記号テーブルに入れる。まず、アク ション１２０６は、返却値を表すのに必要なメモリの量を求める。この量、すな わち返却値の長さはバイト単位で測定される。次いで、アクション１２０６は、 返却値を表すのに必要なメモリの量を用いてメモリ作成ユニット１５００を呼び 出す。メモリ作成ユニット１５００は、返却値を保持するモデル化メモリの部分 を作成し、メモリ・モデル内の新たに作成された位置を指し示すコード化ポイン タをアクション１２０６に返す。メモリ作成ユニット１５００の動作については 以下で詳しく説明する。次に、アクション１２０６は、作成された返却値位置を 指し示すポインタをレイアウトする。第１２図の実施形態では、ポインタの長さ は４バイトである。前述のように、アクション１２０６はメモリ作成ユニット１ ５００を呼び出し、モデル化メモリの適切なサイズの部分を作成し、新たに作成 されたモデル・メモリ位置を指し示すコード化ポインタを受け取る。アクション １２０６は、返却値を指し示すポインタの位置に、返却値の位置のコード化アド レスを格納する。最後に、アクション１２０６は記号テーブルに返却値を入れる 。 アクション１２０６は、記号テーブル・エントリ１３００を作成する。返却値 を含む構文解析ツリー・ノードを指し示すポインタは、フィールド「ｐａｒｓｅ ｔｒｅｅ ｐｏｉｎｔｅｒ」１３０２内に置かれる。「変数」の記号タイプは フィールド「ｓｙｍｂｏｌ ｔｙｐｅ」１３０２内に置かれる。「返却値」はフ ィールド「ｍｅｍｏｒｙ ｔｙｐｅ」１３０６内に置かれる。返却値を保持する ために作成された第１の位置を指し示すコード化ポインタは「ｓｙｍｂｏｌ ｌ ｏｃａｔｉｏｎ」１３０８内に置かれる。返却値を指し示すポインタを格納する ために作成された第２の位置を指し示すコード化ポインタはフィールド「ｓｙｍ ｂｏｌ ｌｏｃａｔｉｏｎ ｐｏｉｎｔｅｒ」１３１０内に置かれる。アクショ ン１２０６では記号テーブルに記号差を格納することはないので、フィールド「 ｐａｒｅｎｔ ｉｎｄｅｘ」１３１２は使用されない。本発明の一実施形態で は、あるルーチンによって記号テーブルに記号テーブル・エントリ１３００が入 れられる。マイクロフィッシュの付録Ａの実施形態では、「ｓｙｍ＿ａｄｄ＿ｓ ｙｍｂｏｌ」というラベルの付いたルーチンが記号テーブルに記号テーブル・エ ントリ１３００を入れる。処理は、パスに沿った文の処理アクション１２０８（ 以下では「アクション１２０８」と呼ぶ）へ移る。 アクション１２０８は、現在のパスをトラバースし各文の実行を模倣する責任 を負う。アクション１２０８は、個々の各文タイプの実行をシミュレートまたは エミュレートするのに適切な処理を実行する。アクション１２０８の処理につい ての詳細な議論は、以下に見出し「文の分析」の下で提示する。現在のパスに沿 って各文を処理するアクション１２０８が終了した後、処理は記号テーブル順序 付けアクション１２１０（以下では「アクション１２１０」と呼ぶ）へ移る。本 発明の一実施形態では、アクション１２０８はあるルーチンによって実現される 。マイクロフィッシュの付録Ａの実施形態では、「ｅｘｅ＿ｅｘｅｃｕｔｅ＿ｓ ｔａｔｅｍｅｎｔ」というラベルの付いたルーチンがアクション１２０８の関数 を実行する。 アクション１２１０は、記号テーブルをソートし、分析エンジン３０８によっ てトラバースされる各パスに関する記号テーブル上の順序を同じにする。オート モデル化では、いくつかの異なるパスの結果を比較する必要がある。記号テーブ ルをソートすると、現在のパスを実行した結果を他のパスを実行した結果と比較 するのが容易になる。本発明の一実施形態では、記号テーブルはアルファベット 順にソートされる。 記号テーブルをソートする理由は例を介して最もうまく説明することができる 。オートモデル化中には、後述のように、オートモデル化のために必要な記号テ ーブル内のあらゆる記号が調べられる。記号テーブル・エントリ１３００がポイ ンタである場合は、ポインタ・チェーンをたどる。ポインタ・チェーンに沿った 各位置は、チェーンの先頭にある記号の名前と、その前にある、この位置に到達 するのに必要な各間接参照レベルについてのアスタリスク（「^*」）とでラベル 付けされる。たとえば、第１４ａ図を参照するとわかるように、ｐ１４１２は、 「Ｌｏｃ１」位置１４１６を指し示す記号テーブル１４１０内のポインタである 。 「Ｌｏｃ１」位置１４１６は、ポインタｐ１４１２から１間接参照レベルだけ離 れており、「^*ｐ」とラベル付けされる。「Ｌｏｃ１」位置１４１６は「Ｌｏｃ ２」位置１４１８を指し示す。「Ｌｏｃ２」位置１４１８は、ポインタｐ１４１ ２から２間接参照レベルだけ離れており、「^**ｐ」とラベル付けされる。 記号は、関数のパスに沿って記号に出会う順序で記号テーブル内に置かれる。 関数のそれぞれの異なる経路をトラバースする際にそれぞれの異なる順序で記号 に出会う。第１４ａ図では、コード・パス上でポインタｑ１４１４よりも前にポ インタｐ１４１２に出会っており、したがって、ｐ１４１２は記号テーブル１４ １０ではｑ１４１４よりも前にある。同じ関数中の異なる経路を表す第１４ｂ図 では、ポインタｐ１４１２よりも前にポインタｑ１４１４に出会う。したがって 、第１４ｂ図では、ｑ１４１４は記号テーブル１４２０でｐ１４１２よりも前に 記録される。 ポインタｐ１４１２およびｑ１４１４は、値ゼロを含むメモリ・モデル位置１ ４２４（Ｌｏｃ２）を指し示す共用メモリ・モデル位置１４２２（Ｌｏｃ１）を 指し示す。前述のラベル付けステップを第１４ａ図の記号テーブル１４１０に対 して実行すると、結果は「^*ｐ＝０」になる。この結果は、チェーンがポインタ ｐ１４１２から始まることに基づいて「Ｌｏｃ１」位置１４１６を^*ｐとラベル 付けすることから導かれる。ラベル付け演算を第１４ｂ図の記号テーブル１４２ ０に対して実行すると、結果は「^*ｑ＝０」になる。この結果は、チェーンがポ インタｑ１４１４から始まることに基づいて位置１４２２「Ｌｏｃ１」を^*ｑと ラベル付けすることから導かれる。２つのパスは共に同じ実際の結果を有するが 、式が異なる（「^*ｐ＝０」と「^*ｑ＝０」）ので、結果を併合することは難しい 。 記号テーブルをソートすると、ポインタｐ１４１２は常にポインタｑ１４１４ よりも前に処理される。このように、２つのパスは共に結果を「^*ｐ＝０」とし て表す。記号テーブルを順序付けることによって、２つのパスの結果を単一の結 果に併合することができる。したがって、記号テーブルを順序付けると、オート モデル化処理によって、いくつかの異なるパスの結果を容易に比較することがで きる。本発明の一実施形態では、あるルーチンによって記号テーブルが順序付け される。マイクロフィッシュの付録Ａの実施形態では、ルーチン「ｓｙｍ＿ｏｒ ｄｅｒ＿ｔａｂｌｅ」が記号テーブルを順序付ける。処理はアクション１２１０ からリーク検出アクション１２１２（以下では「アクション１２１２」と呼ぶ） へ移る。 アクション１２１２はリーク検出処理を実行する。アクション１２１２は、す べてのモデル化メモリを巡回し、現在のパスを分析する間に累積されたメモリ割 付けに関する情報を走査する。アクション１２１２は、現在の関数が終了する際 にリークするメモリのチャンクを識別する。割付け時にはメモリの一部がリーク するが、このことが、関数が終了した後に記号によって指摘されることはない。 アクション１２１２は、リークした資源も検出する。アクション１２１２によっ て実行される処理の詳細な説明は、以下に見出し「リーク検出」の下で与える。 処理はアクション１２１２からｐｒａｇｍａ＿ｏｐｔｉｏｎリセットアクション １２１４（以下では「アクション１２１４」と呼ぶ）へ移る。 アクション１２１４は、アクション１２０２で設定された構成オプションを再 生する。現在の関数にプラグマが定義されている場合、アクション１２１４は、 このプラグマに指定されている構成オプションをアクション１２０２で保存され た値に設定する。アクション１２１４は、処理をパスごとデータ構造解放または クリーンナップアクション１２１６（以下では「アクション１２１６」と呼ぶ） へ移す。 パスごと処理はアクション１２１６で終了し、パスごとに使用される記憶域が クリーンナップされ、グローバル・データ構造が現在のパスに関する情報で更新 される。第１３図の実施形態では、あるルーチンを実行することによって、パッ ケージ内のパスごとデータ構造が解放またはクリーンアップされる。このような ルーチンは、アクション１２０４で実行されるルーチンとは逆のパッケージ順で 呼び出される。アクション１２１６によって呼び出されるルーチンは、ｅｘｅ、 ａｕｔｏ、ｃｐｈ、ｉｎｓ、ｓｙｍ、ｖｉｍ、ｅｒｒ、ｍｃｉｌ、ｃｔｘのパッ ケージ順で呼び出される。マイクロフィッシュの付録Ａの実施形態では、アクシ ョン１２１６によって呼び出されるルーチンには「ｐｋｇ＿ｅｎｄ＿ｐａｔｈ」 というラベルが付けられる。この場合、「ｐｋｇ」はパッケージの名前を表す。 たとえば、ｅｘｅパッケージ内のパスごとデータ構造は、「ｅｘｅ＿ｅｎｄ＿ｐ ａｔｈ」というラベルの付いたルーチンによって解放される。ａｕｔｏパッケー ジに対応するアクション１２１６によって実行されるルーチンは、現在のパスの 「実行」に関する情報を収集し、現在の関数のモデル１１８を作成する際に助け となるので特に重要である。オートモデル化については以下で詳しく説明する。 アクション１２１６が完了すると、パスごと処理が終了する。メモリ作成ユニット１５００ 前述のように、メモリ作成ユニット１５００は、メモリをモデル化するために 必要なデータ構造を作成する。分析エンジン３０８によって作成されたメモリ・ モデルは、実行中にプログラムが使用するメモリを表している。分析エンジン３ ０８は構造上のメモリ・モデルを作成する。というのは、そのモデルは値ではな く値の内部合成物（ｃｏｍｐｏｓｉｔｉｏｎ）を単一ユニットとして模倣するか らである。たとえば、Ｃ言語プログラムを分析する本発明の一実施形態では、倍 長整数は、１つの単一アドレス可能値とは対照的に、個々にアドレス可能な４バ イトの合成物として表されている。しかし、メモリ・モデルは、一時値を格納す るために多くのコンピュータ・プログラムが使用するヒープ記憶域のように、物 理的に隣接しているわけではない。 メモリ・モデルは、チャンク（ｃｈｕｎｋ）・テーブルと、チャンク１７００ と、ポインタによってまとめてリンクされた格納値１８００から構成される。前 述のように、チャンク・テーブルはモデル化メモリのすべてを記録する。チャン ク１７００は、１つまたは複数の隣接メモリ位置をモデル化する。格納値１８０ ０は、１つまたは複数のメモリ位置（すなわち、チャンク１７００）に格納され た値を保持する。チャンク１７００および格納値１８００については以下に詳述 する。メモリ作成ユニット１５００の処理は、起点情報収集アクション１５０２ （以下「アクション１５０２」という）から始まる。 アクション１５０２は、メモリが作成されるコンテキストを追跡するものであ る。アクション１５０２は、メモリ作成ユニット１５００が処理を開始したとき にコンテキスト情報をカプセル化する起点コンテキスト構造１６００を作成する 。起点コンテキスト構造１６００は、後述するようにチャンク１７００に格納さ れ る。起点コンテキスト構造については第１６図に示す。起点コンテキスト構造１ ６００は、「外部ＩＤタイプ」１６０２と、「外部ＩＤ」１６０４と、「メモリ ・タイプ」１６０６と、「ステートメントの作成元」１６０８と、「式の起点」 １６１０と、「エミュレーション中フラグ」１６１２と、「ソース・コード・フ ァイル」１６１４と、「ソース行番号」１６１６と、「入力名」１６１８と、「 出力名」１６２０というフィールドを含む。 フィールド「外部ＩＤタイプ」１６０２は、その記憶域が作成された項目のタ イプを示す。本発明の一実施形態で可能な項目タイプは、「記号」、「格納値」 、「文字列」、「戻り値」、「未知」である。「格納値」については後述するが 、「未知」は項目タイプを決定できないことを意味する。「記号」および「文字 列」というタイプの項目は、当業者には周知のものである。フィールド「外部Ｉ Ｄ」１６０２は、モデル化したメモリの作成をトリガする項目を明確に識別する 現行構文解析ツリー構造３０４内のノードを指すポインタを含む。 フィールド「メモリ・タイプ」１６０６は、何のためにそのメモリが作成され るのかを分類する。以下に詳述するように、フィールド「メモリ・タイプ」１６ ０６はモデル化のために使用する。その関数の外部で可視の項目のためにメモリ を作成している場合、それは自動モデル化の際に使用されることになる。本発明 の一実施形態では、モデル化したメモリのタイプは、定数、グローバル、グロー バルのデリファレンス、スタティック、スタティックのデリファレンス、ローカ ル、パラメータ、パラメータのデリファレンス、ヒープ・メモリ、資源定義、資 源、一時、未知、アドレス定数、文字定数、ゼロ定数である。当業者であれば、 定数、グローバル、ローカル、スタティック、パラメータ、戻り値の各項目につ いては分かるだろう。 前述のように、デリファレンスとは、ポインタが指し示す値を意味する。たと えば、グローバルのデリファレンスは、グローバル変数が指し示す値を保持する メモリ位置を示す。「未知」というメモリ・タイプは、モデル化したメモリの区 画がその関数の外部で可視ではないことを示す。メモリ・タイプが「未知」の項 目は、現行関数用のモデル１１８を作成する際に使用しない。一時値は、現行関 数が実行する計算の中間ステップから得られ、現行構文解析ツリー構造３０４で 識別される。ヒープ・メモリは現行関数が割り振ったメモリである。たとえば、 Ｃ言語の「ｍａｌｌｏｃ（１０）」という関数呼出しは１０バイトのヒープ・メ モリを作成する。資源および資源定義は、ファイルおよびウィンドウなど、関数 が使用するオブジェクトを示す。 より一般的な「定数」メモリ・タイプは、分析エンジン３０８内の処理の最適 化を見込んでおくために、アドレス、文字、文字列定数という特定のケースとは 区別される。ゼロは頻繁に使用される数なので、分析エンジン３０８は、現行関 数で使用するたびに定数ゼロのインスタンスを１つだけモデル化する。他の定数 タイプとは対照的に、アドレス定数だけがデリファレンスされるので、リーク検 出処理が改善される。項目が有効ポインタであるかどうかを判定するチェックは 、文字定数については行う必要がないので、全体的な効率が改善される。最適化 されたメモリ管理および意志決定によって、分析エンジン３０８のパフォーマン スが改善される。 フィールド「ステートメントの作成元」１６０８は、フィールド「外部ＩＤ」 １６０４で識別された項目を含むステートメントを識別する現行構文解析ツリー 構造３０４内の構文解析ツリー・ノードを指すポインタである。フィールド「式 の起点」１６１０は、フィールド「外部ＩＤ」１６０４で識別された項目を含む 式を識別する現行構文解析ツリー構造３０４内の構文解析ツリー・ノードを指す ポインタである。フラグ「エミュレーション中フラグ」は、モデル化メモリがモ デル１１８の実行のために作成されるときに真になる。フィールド「ソース・コ ード・ファイル」１６１４は、現行関数を含むソース・コード・ファイルの名前 を識別する。フィールド「ソース行番号」１６１６は、フィールド「ステートメ ントの作成元」１６０８によって識別されるステートメントのフィールド「ソー ス・コード・ファイル」１６１４によって識別されるソース・コード・ファイル 内の行番号を識別する。フィールド「入力名」１６１８は、作成中のモデル化メ モリの区画に関連する元の格納値の名前を含む。フィールド「出力名」１６２０ は、作成中のモデル化メモリの区画に関連する最終値の名前を含む。フィールド 「入力名」１６１８およびフィールド「出力名」１６２０は、モデル化している メモリ位置が現行関数の開始時（「入力名」１６１８）または終了時（「出力名 」 １６２０）のいずれでアクセス可能であるかを記録するために自動モデル化プロ グラムによって使用される。起点コンテキスト構造１６００に適切に記入した後 、処理はアクション１５０４に移行する。 アクション１５０４は、１つまたは複数の隣接メモリ位置用のモデルを作成す るものである。メモリ位置は、アドレスによって明示的かつ明確に指定可能なメ モリの最小単位である。通常、コンピュータ・メモリはバイト・アドレス可能で あり、したがって、１つの位置は１バイトである。アクション１５０４は、チャ ンク１７００を使用してメモリをモデル化する。チャンク１７００については第 １７図に示す。チャンク１７００は、「解放フラグ」１７０２と、「到達可能フ ラグ」１７０４と、「紛失フラグ」１７０６と、「メモリ・タイプ」１７０８と 、「チャンク番号」１７１０と、「起点コンテキスト構造ポインタ」１７１２と 、「格納値ポインタ」１７１４と、「元の格納値ポインタ」１７１６というフィ ールドを含む。 フラグ「解放フラグ」は、チャンク１７００によってモデル化されたメモリ位 置が解放されたときに真になる。フラグ「到達可能フラグ」１３０２は、そのメ モリ位置が到達可能であるかどうかを判定するためにリーク検出処理が使用する 。フラグ「紛失フラグ」１７０６は、モデル化したメモリが解放されるかまたは リークされるかどうかを判定できないときに真になる。紛失メモリの場合、関数 が終了したあとでメモリを指し示すものが何もない可能性があるが、メモリを指 すポインタのレコードがないというだけで、このようなポインタが存在しないこ とを意味するわけではない。たとえば、欠落モデルによってモデル化されるルー チンにメモリを割り振って、渡すことができる。分析エンジン３０８は、ルーチ ンに渡された割振りメモリに何が起きたのかを確かめることができない。したが って、そのメモリは「紛失」としてマークされる。フィールド「メモリ・タイプ 」１７０８は、前述のフィールド「メモリ・タイプ」１６０６と同じ情報を保持 する。フィールド「チャンク番号」１７１０は、チャンク１７００用の固有の識 別子である。フィールド「起点コンテキスト構造ポインタ」１７１２は、アクシ ョン１５０２で作成された起点コンテキスト構造１６００を指し示す。フィール ド「格納値ポインタ」１７１４は、モデル化メモリ位置にある現行値を指し示す 。 フィールド「元の格納値ポインタ」１７１６は、モデル化メモリ位置にある元の 値を指し示す。 まず、アクション１５０４は、チャンク１７００を再使用できるかどうかを判 定するために、チャンク・テーブル内を反復してチャンク１７００を調べる。ア クション１５０４がチャンク１７００を再使用できない場合、新しいチャンク１ ７００を作成しなければならない。新しいチャンク１７００を指すポインタはチ ャンク・テーブル内に配置される。チャンク番号１７１０には、新しいチャンク １７００を明確に識別する番号が割り当てられる。フラグ「解放フラグ」１７０ ２、「到達可能フラグ」１７０４、「紛失フラグ」１７０６は、偽に初期設定さ れる。フィールド「メモリ・タイプ」１７０８は、アクション１５０２で設定さ れた「メモリ・タイプ」１６０６と等しくなるように設定される。フィールド「 起点コンテキスト構造ポインタ」１７１２は、アクション１５０２で構築された 起点コンテキスト構造１７００を指し示すように設定される。次に処理は、格納 値セットを作成するために値モデル化アクション１５０６（以下「アクション１ ５０６」という）に移行する。 アクション１５０６は、アクション１５０４で作成したチャンク１５００によ ってモデル化された位置に配置された値をモデル化するものである。メモリ作成 ユニット１５００は、格納値セットを作成することによって値をモデル化する。 格納値セットは格納値の集合である。各格納値は、１単位分のメモリを表すデー タ構造である。第１５図の実施形態では、メモリ作成ユニット１５００は、Ｃコ ンピュータ言語のメモリ管理特性を模倣する。Ｃコンピュータ言語は、隣接バイ ト・セットとして値を割り振る。各格納値は１バイト分のメモリを表す。したが って、１セット分の格納値は、１つの値を格納するために使用するバイトの集合 を表す。たとえば、正規整数は、通常、長さ４バイトである。アクション１５０ ６は、４つの格納値を作成し、それを格納値セット内に配置することによって整 数をモデル化する。 アクション１５０６は、作成中のメモリの各バイトごとに１つの格納値を作成 する。作成した各格納値を指すポインタは格納値セット内に配置される。したが って、格納値セットは、格納値を指すポインタの集合になる。格納値は、格納値 ブロック１８００によって表される。格納値ブロック１８００については第１８ 図に示す。格納値ブロック１８００は、「起点ポインタ」１８０２と、「資源フ ラグ」１８０４と、「正確値既知フラグ」１８０６と、「初期設定済みフラグ」 １８０８と、「想定値フラグ」１８１０と、「制約フラグ」１８１２と、「結果 フラグ」１８１４と、「保護フラグ」１８１６と、「正確値」１８１８と、「入 力からのバイト」１８２０と、「出力からのバイト」１８２２というフィールド を含む。 フィールド「起点ポインタ」１８０２は、アクション１５０２で作成した起点 コンテキスト構造１６００を指し示す。フラグ「資源フラグ」１８０４は、この データ構造が格納値または格納資源のいずれを表すかを識別する。フラグ「資源 フラグ」１８０４は、データ構造が格納値を表す場合に必ず偽になる。資源は格 納値と同様に表されるが、格納値ブロック１８００の代わりに格納資源ブロック １９００を使用する。格納資源ブロック１９００については後述する。フラグ「 正確値既知フラグ」１８０６は、フィールド「正確値」１８１８が有効値を含む ときに真になる。フラグ「想定値フラグ」１８１０は、この値が処理中に想定さ れた場合に真になる。フラグ「制約フラグ」１８１２は、モデル１１８内の制約 でこの値を使用できる場合に真になる。フラグ「結果フラグ」１８１４は、モデ ル１１８内の結果でこの値を使用できる場合に真になる。フラグ「保護」は、モ デル１１８内の保護でこの値を使用できる場合に真になる。制約、結果、保護に ついては「概念のモデル化」という見出しの項で詳述する。フィールド「正確値 」１８１８は、モデル化メモリ位置に格納された正確値を含む。フィールド「入 力からのバイト」１８２０は、この格納値に対応する（「元の格納値ポインタ」 １７１６が指し示す）元の格納値セット内の特定のバイトを識別する。フィール ド「出力からのバイト」１８２２は、この格納値に対応する（「格納値ポインタ 」１７１４が指し示す）最終格納値セット内の特定のバイトを識別する。 あるいは、資源用のメモリをモデル化するためにメモリ作成ユニット１５００ を呼び出す場合、アクション１５０６は、格納資源ブロック１９００を作成する ことになる。格納資源ブロック１９００については第１９図に示す。格納資源ブ ロック１９００は、「起点ポインタ」１９０２と、「資源フラグ」１９０４と、 「リーク可能フラグ」１９０６と、「到達可能フラグ」１９０８と、「紛失フラ グ」１９１０と、「想定フラグ」１９１２と、「資源タイプ」１９１４と、「資 源状態」１９１６というフィールドを含む。 フィールド「起点ポインタ」１９０２は、アクション１５０２で作成した起点 コンテキスト構造１６００を指し示す。フラグ「資源フラグ」１９０４は、この データ構造が格納値または格納資源のいずれを表すかを識別する。フラグ「資源 フラグ」１９０４は、データ構造が格納資源を表す場合に必ず真になる。フラグ 「リーク可能フラグ」１９０６は、現行関数が終了したあとで資源を指し示すこ とができないときに真になる。フラグ「到達可能フラグ」１９０８は、後述する ようにリーク検出処理の際に使用する。フラグ「紛失フラグ」１９１０は、現行 関数が終了したあとで資源を指し示すかどうかを分析エンジン３０８が予測でき ないことを示す。フラグ「想定フラグ」１９１２は、分析エンジン３０８での処 理中に資源が想定されたときに真になる。フィールド「資源タイプ」１９１４お よび「資源状態」１９１６は、モデル化メモリを必要とする資源のタイプと状態 をそれぞれ保持する。必要な数の格納値ブロック１８００または格納資源ブロッ ク１９００が作成され、格納値セット内に配置された後、処理はメモリ位置と値 とのリンク・アクション１５０８（以下「アクション１５０８」という）に移行 する。 アクション１５０８は、モデル化値（または資源）をモデル化メモリ位置にリ ンクするものである。これがチャンク１７００について第１の格納値セットであ る場合、格納値ポインタ１７１４と元の格納値ポインタ１７１６の両方は、アク ション１５０４で作成した格納値セットを指し示すように設定される。そうでは ない場合、格納値ポインタ１７１４だけが、アクション１５１４で作成した格納 値セットを指し示すように設定される。このようにして、１つの位置に関する元 の格納値セットと、１つの位置に関する最新格納値セットがチャンク１７００に 記憶される。格納値の中間インスタンスは自動モデル化には必要ないので廃棄さ れる。モデル１１８は、関数が求める結果を記述するものであって、結果に到達 する方法を記述するものではない。したがって、中間インスタンスではなく、格 納値の初期インスタンスと最終インスタンスだけが、自動モデル化のために検査 される。 メモリ作成ユニット１５００用の処理は終了し、アクション１５０８はメモリ 作成ユニット１５００の呼出し側に新たにモデル化したメモリを指す符号化ポイ ンタを返す。符号化ポインタは、チャンク１７００を指すポインタと、格納値ポ インタ１７１２が指し示す格納値セットへのオフセットからなる。モデル化メモ リ内の位置はシミュレートしたメモリ位置なので、符号化ポインタが必要になる 。たとえば、第２０図に示すようにメモリをモデル化するために使用するデータ 構造間のリンクの簡略図を参照されたい。チャンク２００４は、チャンク・テー ブル２００２内の項目によって配置される。次にチャンク２００４は、関連の格 納値セット２００６を指すポインタを含む。格納値セット２００６へのオフセッ トは、格納値２００８、２０１０、２０１２を指すポインタである。したがって 、モデル化メモリ内では、真のメモリ位置とは異なり、単純な物理アドレスによ って値にアクセスすることができない。このため、モデル・メモリ位置、または より単純に位置は、格納値ブロック１８００を指す符号化ポインタになる。リーク検出 前述のように、リークは、パス内のステートメントが処理されたあとでパス分 析の終わりにアクション１２１２で検出される。メモリ・リークは、マーク・ス ウィープ方法を使用して検出される。まず、アクション１２１２は、チャンク・ テーブル内を反復し、各チャンクを到達不能としてマークする。チャンク１７０ ０は、フラグ「到達可能フラグ」１７０４を偽に設定することによって到達不能 としてマークされる。次に、アクション１２１２は、記号テーブル内の各外部内 を反復し、ポインタ連鎖のみを移動する。アクション１２１２は、ポインタ連鎖 内で検出された各チャンク１７００を到達可能としてマークする。チャンク１７ ００は、フラグ「到達可能フラグ」１７０４を真に設定することによって到達可 能としてマークされる。記号テーブルを処理した後、アクション１２１２は、チ ャンク・テーブル内を反復して各チャンク１７００を検査する。各チャンクごと に、それがヒープ記憶域であって、解放も紛失もされておらず、依然として到達 不能としてマークされている場合、そのチャンクはリーク済みとして報告される 。 本発明の一実施形態では、メモリ・リークは、対応する故障インジケータ１０６ によって報告される。 また、アクション１２１２は資源リークも報告する。チャンク・テーブル内で もう一度反復が行われるが、今回のアクション１２１２は、資源を示すようにフ ィールド「メモリ・タイプ」１７０８が設定されたすべてのチャンク１７００を サーチする。資源を定義する各チャンクごとに、対応する格納資源ブロック１９ ００に対して問合せを行う。資源が到達可能ではなく、認識された状態の１つに なっていない場合、それはリーク済みとして報告される。認識された状態として は、閉、解放、リリース済み、削除済みがある。本発明の一実施形態では、資源 リークは対応する故障インジケータ１０６によって報告される。ステートメント分析 アクション１２０８は、前述のように、現行パスに沿って各ステートメントの 実行の模倣を担当する。分析中の現在のステートメントを現行ステートメントと 称する。アクション１２０８は、さらに処理するために現行ステートメントを識 別し、分散する。アクション１２０８については第２２図のブロック図に示す。 アクション１２０８用の処理は、プラグマ読取りアクション２２０２（以下「ア クション２２０２」という）から始まる。 アクション２２０２は、現行ステートメント用にプラグマが定義されているか どうかを判定するものである。前に提示したように、プラグマは、プラグマの直 後の関数またはステートメントに関する制御を設定するＩｎｔｒｉｎｓａ指示文 である。ステートメントの直前のソース・コード内に配置されたＩｎｔｒｉｎｓ ａプラグマは、その特定のステートメントのみを制御するための構成オプション を指定する。たとえば、以下のプラグマは、「ａ＝１＋２；」というステートメ ントのみに適用される。 ＃ｐｒａｇｍａ ＩＮＴＲＩＮＳＡ“ｓｕｐｐｒｅｓｓ＝ｎｕｌｌ＿ｐｏｉｎｔ ｅｒ，ｕｎｉｎｉｔｉａｌｉｚｅｄ” ａ＝１＋２； ｂ＝ａ； 「ｓｕｐｐｒｅｓｓ」構成オプションに関する詳細は付録Ｂに記載されている 。アクション２２０２は、プラグマを検出した場合、まず、プラグマによって指 定された構成オプションの現行設定を保管し、次に、プラグマ内に指定された値 に応じてこれらの構成オプションを設定する。処理は、アクション２２０２から コンテキスト情報更新アクション２２０４（以下「アクション２２０４」という ）に移行する。 アクション２２０４は、実行コンテキスト・ブロック２１００にコンテキスト 情報を通知するものである。現行ステートメント２１１０は、現行ステートメン トを表す現行構文解析ツリー構造３０４内のノードを指し示すように設定される 。 現行行番号２１１２は、現行ステートメントを含む現行関数を格納するファイル 内の行番号に設定される。処理は、アクション２２０４から個々のステートメン ト・タイプに基づく直接処理アクション２２０６（以下「アクション２２０６」 という）に移行する。 アクション２２０６は、さらに処理するためにステートメント・ユニットに分 散することにより、個々のステートメントを処理するものである。アクション２ ２０６は、まず、分析中のステートメントのタイプを識別する。次にアクション ２２０８は、処理制御を対応するステートメント・ユニットに移転する。第２２ 図の実施形態に関して、表３は、ステートメントのタイプと呼び出されたステー トメント・ユニットとの対応関係を示している。「ステートメント・ユニット」 という列に列挙したモジュールについては以下に詳述する。「ステートメント・ タイプ」という列に列挙したステートメント・タイプは、当業者にとって周知も のである。制御がアクション２２０６に戻ると、処理は、プラグマ・オプション ・リセット・アクション２２０８（以下「アクション２２０８」という）に移行 する。 アクション２２０８は、アクション２２０２で設定した構成オプションを復元 するものである。現行ステートメント用にプラグマが定義されている場合、アク ション２２０８は、プラグマ内に指定された構成オプションをアクション２２０ ２で保管した値に設定する。アクション２２０８は処理制御を開始アクション制 御に返す。 次にステートメント・ユニットの説明に移行すると、ブロック・ユニットは、 ブロック・ステートメント内のステートメントによるループを実行する。ブロッ ク・ステートメントは、しばしば複文と呼ばれるが、１つの構文ユニットを形成 する１組のステートメントである。通常、ブロック・ステートメントは、Ｃプロ グラミング言語で書かれた関数内の最高レベルのステートメントである。ブロッ ク・ユニットについては、論理流れ図２３００（第２３図）として詳細に示す。 パス終了判断２３０１（以下「判断２３０１１という）では、現在のブロック が終了したかどうかを確認するためにチェックを行う。ｎｕｌｌまたはｅｘｉｔ ステートメントが前に処理されている場合、現行ブロック・ステートメントの分 析は完了し、論理流れ図２３００による処理、したがって、ブロック・ユニット は終了する。現在のブロックが依然として活動状態である場合、処理は、ｇｏｔ ｏステートメントが処理されているかどうかを判定するｇｏｔｏケース判断２３ ０２（以下「判断２３０２」という）に移行する。第２３図の実施形態では、ｇ ｏｔｏ処理は、ｇｏｔｏパラメータに問い合わせることによって識別される。マ イクロフィッシュの付録Ａの実施形態では、ｇｏｔｏパラメータは「ｇｏｔｏ＿ ｓｔａｔｅｍｅｎｔ」と命名されている。ｇｏｔｏステートメントがシミュレー トされることをｇｏｔｏパラメータが示している場合、処理はターゲット判断２ ３０３（以下「判断２３０３」という）に移行し、そうではない場合、処理制御 はステートメント分析アクション２３０５（以下「アクション２３０５」という ）に移行する。 判断２３０３は、活動ｇｏｔｏステートメントのターゲットであるステートメ ントに到達したかどうかを確認するためにテストを行う。判断２３０３は、ブロ ック内の現行ステートメントを表す現行構文解析ツリー・ノードを指すポインタ と、ｇｏｔｏターゲット・ステートメントを表す現行構文解析ツリー・ノードを 指すポインタとを比較する。２つのポインタが一致する場合、ブロック内の現行 ステートメントはｇｏｔｏターゲット・ステートメントである。ｇｏｔｏターゲ ット・ステートメントに到達している場合、処理はｇｏｔｏ切断アクション２３ ０４（以下「アクション２３０４」という）に移行する。ブロック内の現行ステ ートメントがｇｏｔｏターゲット・ステートメントではない場合、処理は最終判 断２３０６（以下「判断２３０６」という）に移行する。 アクション２３０４は、処理中の活動ｇｏｔｏステートメントがないことを示 すためにｇｏｔｏパラメータを偽に設定する。アクション２３０４が完了した後 、処理はアクション２３０５に移行する。アクション２３０５はブロック内の現 行 ステートメントを分析するものである。アクション２３０５は、ブロック内の現 行ステートメントを表す現行構文解析ツリー構造３０４内のノードを指すポイン タを取り出し、処理制御とともにそのポインタを再帰的にアクション１２０８に 転送する。制御がアクション２３０５に戻ると、処理は最終判断２３０６に移行 する。 判断２３０６は、現在のブロック・ステートメント内の最終ステートメントが 処理されたかどうかを判定する。判断２３０６が真になる場合、論理流れ図２３ ００による処理、したがって、ブロック・ユニットは終了する。そうではない場 合、最終ステートメントに到達していないので、処理は次の獲得アクション２３ ０９（以下「アクション２３０９」という）に移行する。アクション２３０９は 、ブロック内の次のステートメントを獲得し、判断２３０１に制御を移転して、 現在のブロック・ステートメントの処理を続行する。 式ユニットは式を処理するものである。入力として、式ユニットは、処理すべ き式を表す現行構文解析ツリー構造３０４内のノードを指すポインタを受け取る 。出力として、式ユニットは、式の結果を保持する位置を指すポインタを返す。 「式」という用語は、本明細書では、ＫｅｒｎｉｇｈａｎおよびＲｉｔｃｈｉｅ によるＴｈｅ Ｃ ｐｒｏｇｒａｍｍｉｎｇ ｌａｎｇｕａｇｅ、１８５（Ｐｒ ｅｎｔｉｃｅ−Ｈａｌｌ、１９７８年）に定義されているように使用する。ステ ートメントは、セミコロンとともにそのあとに続くことによって、式から構築す ることができる。本発明の一実施形態では、式ユニットはルーチンによって実現 される。マイクロフィッシュの付録Ａの実施形態では、式ユニットは「ｅｘｅ＿ ｅｖａｌｕａｔｅ＿ｅｘｐｒ」ルーチンによつて実現される。式ユニットについ ては、論理流れ図２４００（第２４図）として詳細に示す。 式の処理は、ｎｕｌｌ式判断２４０２（以下「判断２４０２」という）から始 まる。判断２４０２は、入力式がｎｕｌｌ式と等しいかどうかを判定する。入力 式がｎｕｌｌ式と等しいときは、いかなるアクションも不要であり、論理流れ図 ２４００による処理、したがって、式ユニットは終了する。そうではない場合、 入力式がｎｕｌｌ式と等しくないときは、処理は現行コンテキスト保管アクショ ン２４０４（以下「アクション２４０４」という）に移行する。アクション２４ ０４は、現行式２１１４の値を保管する。処理は、入力式を表す現行構文解析ツ リー構造３０４内のノードを指すポインタを現行式２１１４に格納する新コンテ キスト設定アクション２４０６（以下「アクション２４０６」という）に移行す る。古いコンテキスト情報が保管され、新しいコンテキストが設定された後、処 理は値判断２４０８（以下「判断２４０８」という）に移行する。 判断２４０８は、入力式が値であるかどうかを判定する。構文解析ツリーに関 する前述の説明に戻ると、値は構文解析ツリー内のリーフノードである。一実施 形態の値は、定数、変数、可変アドレス、またはルーチン・アドレスにすること ができる。入力式が値である場合、処理は値探索アクション２４１０（以下「ア クション２４１０」という）に移行し、そうではない場合、処理は演算判断２４ ２２（以下「判断２４２２」という）に移行する。 アクション２４１０は、入力式の値を決定するものである。構文解析ツリー構 造３０４は各値ごとに固有の宣言ノードを有する。宣言ノードは、そのタイプや その内容など、値に関する情報を有する。アクション２４１０は、対応する宣言 ノードを指すポインタを入力式を表すノードから取り出す。また、宣言ノードを 指すポインタは、本明細書ではｅｘｔｅｒｎａｌ＿ｉｄともいう。これは、記号 テーブル内の記号を探索するために使用するｅｘｔｅｒｎａｌ＿ｉｄである。値 の内容の判定は、参照した宣言ノードによって行われる。参照した宣言ノードが 値の内容を含まない場合、その値は「未知」としてフラグが付けられる。処理は 、アクション２４１０から記号テーブル内検出判断２４１２（以下「判断２４１ ２」という）に移行する。 判断２４１２は、値が記号テーブルに格納されているかどうかを判定するもの である。判断２４１２は、アクション２４１０で検出したｅｘｔｅｒｎａｌ＿ｉ ｄと、記号テーブル項目内の構文解析ツリー・ポインタ１３０２とを比較する。 一致が検出された場合、その値は記号テーブル内にあり、処理はコンテキスト復 元アクション２４２８（以下「アクション２４２８」という）に移行する。その 値が記号テーブル内で検出されない場合、処理はメモリ作成アクション２４１４ （以下「アクション２４１４」という）に移行する。 アクション２４１４は、現行式用に（すなわち、値用に）モデル化メモリをレ イアウトするものである。アクション２４１４は、現行関数の戻り値用にモデル 化メモリをレイアウトする前述のアクション１２０６と同様のものである。まず 、アクション２４１４は、現行式を表すために必要なメモリの量を決定する。次 に、アクション２４１４は、メモリ作成ユニット１５００を呼び出して、現行式 を表すために必要な量のメモリをモデル化する。次にアクション２４１４は、（ 参照した宣言ノードで検出された）現行式の内容を新たにモデル化したメモリに 格納する。現行式が変数である場合、アクション２４１４は作成したばかりの現 行式位置を指すポインタをレイアウトする。アクション２４１４は、メモリ作成 ユニット１５００を呼び出して、モデル化メモリのポインタ・サイズの区画を作 成する。アクション２４１４は、現行式の位置の符号化アドレスを現行式を指す ポインタ用の位置に格納する。処理はアクション２４１４から非ゼロ定数判断２ ４１６（以下「判断２４１６」という）に移行する。 判断２４１６は、現行式が非ゼロ定数であるかどうかを判定するものである。 現行式が非ゼロ定数である場合、処理はアクション２４２８に移行し、そうでは ない場合、処理は記号テーブルへの追加アクション２４１８（以下「アクション ２４１８」という）に移行する。アクション２４１８は、現行式を表すための記 号テーブル項目１３００を作成し、新たに作成した記号テーブル項目１３００を 記号テーブルに格納する。ゼロは記号テーブル内に配置される唯一の定数である 。ゼロは、定数ゼロを使用するたびに何度もメモリをモデル化するのを回避する ために最適化として記号テーブル内に配置される。処理はアクション２４１８か らスタティックおよびグローバル変数のリスト保守アクション２４２０（以下「 アクション２４２０」という）に移行する。 アクション２４２０は、自動モデル化のために、グローバル変数のリストとス タティック変数のリストを保守するものである。変数タイプ情報は現行式に対応 する宣言ノードに記録されている。本発明の一実施形態では、変数は、グローバ ル、スタティック、またはローカルのいずれかのタイプにすることができる。現 行式がグローバル変数である場合、アクション２４２０はグローバル変数リスト を更新し、現行式がスタティック変数である場合、アクション２４２０はスタテ ィック変数リストを更新することになる。処理はアクション２４２０からアクシ ョン２４２８に移行する。 入力式が値ではない場合、演算判断２４２２（以下「判断２４２２」という） は、現行式が演算であるかどうかを判定することになる。現行式が演算である場 合、処理は演算処理アクション２４２４（以下「アクション２４２４」という） に移行する。アクション２４２４については以下に詳述する。現行式が演算では ない場合、処理は非評価ケース・アクション２４２６（以下「アクション２４２ ６」という）に移行する。アクション２４２６は、現行式を識別できない場合に 適切なエラー・コードを発行する。現行式が分析エンジン３０８によってサポー トされていない場合、いかなるアクションも行われない。たとえば、第２４図の 実施形態では、「ｎｅｗ」と「ｄｅｌｅｔｅ」というＣ＋＋式はサポートされて いない。処理はアクション２４２６からアクション２４２８に移行する。 アクション２４２８は、アクション２４０４で保管した値を現行式２１１４に 復元する。次に、論理流れ図２４００による処理、したがって、式ユニットは終 了する。終了すると、式ユニットは開始サイト制御に制御を移転する。 演算を処理するアクション２４２４については、論理流れ図２５００（第２５ ａ図、第２５ｂ図）に示す。アクション２４２４は、どのタイプの演算を現行式 が表しているかを判定し、適切な処理を実行する。演算式は、演算子と１つまた は複数のオペランドから構成される。オペランドも式である。処理は、現行式が 関数呼出しを表すかどうかを判定する関数呼出し判断２５０２（以下「判断２５ ０２」という）から始まる。現行式が関数呼出しである場合、処理は、呼び出し た関数をエミュレートする関数エミュレート・アクション２５０４（以下「アク ション２５０４」という）に移行し、そうではない場合、処理は短絡演算判断２ ５０６（以下「判断２５０６」という）に移行する。 アクション２５０４は、その対応モデル１１８を実行することによって関数を エミュレートする。モデル１１８を実行すると、アクション２５０４は、対応す る関数がメモリ・モデルに対してどのような影響を及ぼすか（関数の外部効果） を判定することができる。実行すべき関数が欠落モデルによって表される場合、 アクション２５０４は、関数呼出しが正常に完了すると想定するだけである。付 録Ｆには、アクション２５０４を実現するために使用する一実施形態の擬似コー ドが提示されている。アクション２５０４が完了すると、論理流れ図２５００に よる処理、したがって、アクション２４２４は終了する。 判断２５０６は、現行式が短絡演算であるかどうかをチェックする。短絡演算 子である論理積（＆＆）および論理和（｜｜）はこのように呼ばれる。というの は、（おそらくすべてのオペランドが評価される前に）演算の真理値が決定され ると、ただちに演算の評価が停止するからである。現行式が短絡演算である場合 、処理はＬＨＳ式評価アクション２５０８（以下「アクション２５０８」という ）に移行する。アクション２５０８は、プロセス制御を式ユニット（アクション ２４０２）に移転することにより、演算の左辺式（すなわち、左辺オペランド） を評価する。左辺式を評価した後、処理は、入力式の真理値が決定されたかどう かを判断する真理値決定判断２５１０（以下「判断２５１０」という）に移行す る。入力式が論理積であって左辺式が偽と評価されるか、または入力式が論理和 であって左辺式が真と評価された場合、入力式の真理値が決定され、論理流れ図 ２５００による処理、したがって、アクション２４２４は終了する。そうではな い場合、処理は、処理を式ユニット（アクション２４０２）に移行することによ り現行式の右辺（すなわち、右辺オペランド）を評価するＲＨＳ式評価アクショ ン２５１２（以下「アクション２５１２」という）に移行する。右辺式が評価さ れた後、論理流れ図２５００による処理、したがって、アクション２４２４は終 了する。本発明の一実施形態では、アクション２４２４の処理はルーチンによっ て実行される。マイクロフィッシュの付録Ａの実施形態では、「ｅｘｅ＿ｅｖａ ｌｕａｔｅ＿ｏｐｅｒａｔｉｏｎ」ルーチンがアクション２４２４の処理を実行 する。 現行式が短絡演算ではない場合、処理は、現行式が３項演算子「？：」である かどうかを判定する疑問符演算判断２５１４（以下「判断２５１４」という）に 移行する。現行式が疑問符演算である場合、処理は、疑問符演算のテスト式を評 価するテスト式評価アクション２５１６（以下「アクション２５１６」という） に移行する。テスト式は、式ユニットを呼び出すことによって評価される。テス ト式が評価された後、処理は、テスト式の真理値を検査するテスト式判断２５１ ８（以下「判断２５１８」という）に移行する。テスト式が真と評価された場合 、処理は、「真」というテスト式結果に対応する式を評価する「真」式評価アク シ ョン２５２０（以下「アクション２５２０」という）に移行する。そうではない 場合、処理は、真ではないテスト式結果に対応する式を評価する「偽」式評価ア クション２５２２（以下「アクション２５２２」という）に移行する。アクショ ン２５２０またはアクション２５２２の後、論理流れ図２５００による処理、し たがって、アクション２４２４は終了する。 現行式が疑問符演算ではない場合、処理は、現行式がカンマ演算であるかどう かを判定するカンマ演算判断２５２４（以下「判断２５２４」という）に移行す る。現行式がカンマ演算である場合、処理はＬＨＳ評価（戻り値なし）アクショ ン２５２６（以下「アクション２５２６」という）に移行する。アクション２５ ２６は、カンマ演算の左辺式を評価する。アクション２５２６は、左辺式に関し て返された値を必要としないので、空ポインタを式ユニットに渡す。左辺式の評 価後、処理は、カンマ演算の右辺式を評価するＲＨＳ評価（戻り値）アクション ２５２８（以下「アクション２５２８」という）に移行する。アクション２５２ ８は戻り値を必要とするので、式の結果用の位置を指すポインタによって式ユニ ットを呼び出す。アクション２５２８の後、論理流れ図２５００による処理、し たがって、アクション２４２４は終了する。 現行式がカンマ演算ではない場合、処理は、現行式がビット・フィールドまた はフィールド演算であるかどうかを判定するビット・フィールドおよびフィール ド演算判断２５３０（以下「判断２５３０」という）に移行する。現行式がビッ ト・フィールドまたはフィールド演算である場合、演算子が構造内のフィールド を参照することを意味し、処理はｌｈｓ式評価アクション２５４０（以下「アク ション２５４０」という）に移行する。 アクション２５４０は、式評価ユニットを呼び出すことにより、左辺オペラン ド（すなわち、ｌｈｓ式）を評価する。左辺式は、ビット・フィールドまたはフ ィールド演算が参照する構造を指すポインタである。左辺式が評価された後、処 理制御は、値必要判断２４５２（以下「判断２５４２」という）に移転する。 判断２５４２は、ビット・フィールドまたはフィールド演算がその構造から値 を取り出すかどうかを判定する。演算が値を必要とする場合、処理はメモリ作成 アクション２５４４（以下「アクション２５４４」という）に移行し、そうでは ない場合、処理制御はｒｈｓ ａｒｇとしてのオフセットの使用アクション２５ ４６（以下「アクション２５４６」という）に移転する。アクション２５４４は 、演算が参照する値用のメモリを作成するものである。アクション２５４４は、 メモリ作成ユニット１５００を呼び出して、構造参照の結果得られる値を保持す るために十分な大きさのモデル化メモリの区画を作成する。必要なモデル化メモ リが作成された後、処理はアクション２５４６に移行する。 アクション２５４６は、右辺オペランドに対応する引数情報ブロック２６００ に、位置情報ではなくフィールド・オフセット情報を記入することにより、演算 ユニットを呼び出すための準備を行う。引数情報ブロック２６００については以 下に詳述する。処理制御は演算評価アクション２５３８に移転する。 現行式がビット・フィールドまたはフィールド演算ではない場合、処理はＬＨ Ｓ式評価アクション２５３２（以下「アクション２５３２」という）に移行する 。処理制御がアクション２５３２に到達した場合、現行式が特殊ケースの処理を 必要としないことが分かっており、「通常」演算処理が始まる。アクション２５ ３２は、現行式の左辺を評価するものである。すべての演算は少なくとも１つの 左辺オペランドを有することになる。左辺式が評価された後、処理は、現行式が ２項演算であるかどうかを判定する２項演算判断２５３４（以下「判断２５３４ 」という）に移行する。現行式が２項演算である場合、処理は、現行式の右辺を 評価するＲＨＳ式評価アクション２５３６（以下「アクション２５３６」という ）に移行する。右辺式が評価された後または現行式が単項演算であると判定され た後、処理は演算評価アクション２５３８（以下「アクション２５３８」という ）に移行する。 アクション２５３８は、評価すべき演算を表す演算子と、引数情報ブロック２ ６００（第２６図）内にパッケージ化された演算子の各オペランドとを指定して 演算ユニットを呼び出すことにより、演算を評価するものである。前述のように 、現行式がビット・フィールドまたはフィールド演算である場合、右辺オペラン ドに対応する引数情報ブロック２６００は実際には、モデル化メモリ位置とは対 照的に、構造内へのオフセットを表す。引数情報ブロック２６００は、「位置ポ インタ」２６０２と、「サイズ」２６０４と、「ブール」２６０６と、「ポイン ト からサイズ」２６０８と、「ポイント間からサイズ」２６１０と、「ビット・フ ィールド・フラグ」２６１２と、「ビット・オフセット」２６１４と、「ビット ・サイズ」２６１６と、「印字式」２６１８というフィールドを含む。 フィールド「位置ポインタ」２６０２は、現在の引数ブロック２６００に対応 する引数のモデル化メモリ用の符号化ポインタに設定される。各オペランドは、 別々の引数ブロック２６００によって記述される。フィールド「サイズ」２６０ ４は、フィールド「位置ポインタ」２６０２が指し示すメモリのサイズに設定さ れる。一部の演算はブール値を返し、返されたブール値はフィールド「ブール」 ２６０６に格納される。フィールド「ポイントからサイズ」２６０８は、フィー ルド「位置ポインタ」２６０２が指し示すモデル化メモリ位置にある値が指し示 すもののサイズを保持する。フィールド「ポイント間からサイズ」２６１０は、 フィールド「位置ポインタ」２６０２が参照する値が指し示す位置にある値が指 し示すもののサイズを保持する。フラグ「ビット・フィールド・フラグ」２６１ ２は、フィールド「位置ポインタ」２６０２がビット・フィールドであるときに オンになる。フィールド「ビット・オフセット」２６１４は、ビット・フィール ドの開始点を示す。フィールド「ビット・サイズ」２６１６は、ビット・フィー ルドのビット単位のサイズを保持する。フィールド「印字式」２６１８は、引数 情報ブロック２６００に記述された値を含む式を印字可能なフォーマットで格納 する。 演算ユニットから戻った後、論理流れ図２５００による処理、したがって、ア クション２４２４は終了する。終了すると、アクション２４２４はアクション２ ４２８（第２４図）に処理を移転する。 演算ユニットについては論理流れ図２７００（第２７図）に示す。一般に、演 算ユニットは組込みモデルを実行して、演算の結果を判定する。組込みモデルは モデル１１８と同様のものである。モデル制約と同様に、実行すべき演算につい て真になるべきものが真になっていることを確認するテストが行われる。次に、 モデル結果と同様に、演算を実行したあとで真であることが確認されるものを記 述する結果が生成される。演算ユニットはいつでも結果の位置を返す。返された 位置が空になることもありうる。演算ユニットの処理はテスト選択アクション２ ７０２（以下「アクション２７０２」という）から始まる。本発明の一実施形態 では、演算ユニットの処理はルーチンによって行われる。マイクロフィッシュの 付録Ａの実施形態では、「ｉｎｓ＿ｅｖａｌｕａｔｅ＿ｏｐｅｒａｔｉｏｎ」と いうルーチンが演算ユニットの処理を実行する。 アクション２７０２は、評価中の演算について実行すべきテストを選択する。 実行するために使用可能なテストとしては、「ｃｏｍｐａｒａｂｌｅ」、「ｖａ ｌｉｄ＿ｐｏｉｎｔｅｒ」、「ｉｎｉｔｉａｌｉｚｅｄ」、「ｎｏｎ＿ｚｅｒｏ 」がある。「ｃｏｍｐａｒａｂｌｅ」テストは、２つのポインタが同じ格納値セ ットを指し示すかどうかを判定する。分析エンジン３０８はメモリを正確に複製 するわけではないので、２つのポインタは、モデル化メモリの同じ区画を指し示 す場合のみ、比較することができる。「ｖａｌｉｄ＿ｐｏｉｎｔｅｒ」テストは 、その位置が有効なポインタ、すなわち、モデル化メモリのうちの現在使用中の 区画を指すポインタを含むかどうかを判定する。「ｉｎｉｔｉａｌｉｚｅｄ」テ ストは、所与の位置に値があるかどうかを判定する。「ｉｎｉｔｉａｌｉｚｅｄ 」テストは、その位置に対応する格納値ブロック１８００を調べ、フラグ「初期 設定済みフラグ」１８０８をチェックして、その値が初期設定されているかどう かを判定する。「ｎｏｎ＿ｚｅｒｏ」テストは、ある位置が定数ゼロ以外の値を 含むかどうかを判定する。このテストは、ゼロに等しい除数に関するスクリーニ ングのために使用する。各演算ごとに、適用するテストと、そのテストが適用さ れるオペランドを付録Ｃに列挙する。 適切なテストが選択された後、処理はフィールド演算子判断２７０４（以下「 判断２７０４」という）に移行する。判断２７０４は、分析中の演算子がビット ・フィールドまたはフィールド演算子であるかどうかを判定する。分析中の演算 子がフィールド演算子である場合、処理はオフセット・メモリ作成アクション２ ７０６（以下「アクション２７０６」という）に移行し、そうではない場合、処 理は単項演算子判断２７１８（以下「判断２７１８」という）に移行する。 アクション２７０６は、右辺引数に対応する引数情報ブロック２６００に格納 されたフィールド構造内のオフセットを保持するためにモデル化メモリの区画を 作成する。このオフセットは、新たに作成したモデル化メモリ位置に格納される 。 処理はテスト実行アクション２７０８（以下「アクション２７０８」という）に 移行する。 アクション２７０８は、アクション２７０２で選択したテストを実行する。実 行すべき各テストごとに、アクション２７０８は、分析中の演算子と、テスト中 のオペランドに対応する引数情報ブロック２６００と、テストが成功したかどう かを報告する条件変数とを指定してｖｉｍ基本テスト・ユニットを呼び出す。ｖ ｉｍ基本テスト・ユニットは、指示したテストを実行するためにメモリ・モデル に問い合わせる。ｖｉｍ基本テスト・ユニットについては以下に詳述する。選択 したすべてのテストが実行された後、処理は加算演算子適用アクション２７１０ （以下「アクション２７１０」という）に移行する。 アクション２７１０は、分析中の演算子と、左辺オペランド（すなわち、構造 の位置）に対応する引数情報ブロック２６００と、右辺オペランド（すなわち、 構造内へのオフセットの位置）に対応する引数情報ブロック２６００と、結果位 置を指すポインタと、演算によって１が生成される場合に真理値を保持するため の条件変数とを指定してｖｉｍ基本評価ユニットを呼び出すことにより、ポイン タ加算演算子を評価する。ｖｉｍ基本評価ユニットは、指示した演算の結果を達 成するようにメモリ・モデルを操作する。ｖｉｍ基本評価ユニットについては以 下に詳述する。ポインタ加算演算子の結果は、構造内の参照フィールドを指すポ インタである。加算演算を評価した後、処理はフィールド値必要判断２７１２（ 以下「判断２７１２」という）に移行する。 判断２７１２は、フィールド演算子がフィールドの値を必要とするかどうかを 判定する。フィールド演算子は、構造内の参照フィールドの内容を返すときに値 を必要とする。フィールド値が必要である場合、処理はテスト実行アクション２ ７１４（以下「アクション２７１４」という）に移行し、そうではない場合、論 理流れ図２７００による処理、したがって、演算ユニットは終了する。 アクション２７１４は、アクション２７０８と同様に、アクション２７０２で 選択したテストを実行する。テストが実行された後、処理はデリファレンス演算 子適用アクション２７１６（以下「アクション２７１６」という）に移行する。 アクション２７１６は、分析中の演算子と、左辺オペランド（すなわち、構造内 の参照フィールドを指すポインタ）に対応する引数情報ブロック２６００と、結 果位置を指すポインタと、演算によって１が生成される場合に真理値を保持する ための条件変数とを指定してｖｉｍ基本評価ユニットを呼び出すことにより、ポ インタ・デリファレンス演算子を評価する。ｖｉｍ基本評価ユニットは、指示し た演算の結果を達成するようにメモリ・モデルを操作する。ポインタ・デリファ レンス演算は、構造内の参照フィールドの内容を返す。ポインタ・デリファレン ス演算子を評価した後、論理流れ図２７００による処理、したがって、演算ユニ ットは終了する。 判断２７１８は、分析中の演算子が単項演算子であるかどうかを判定する。分 析中の演算子が単項演算子である場合、処理はテスト実行アクション２７２０（ 以下「アクション２７２０」という）に移行し、そうではない場合、処理は２項 演算子判断２７２４（以下「判断２７２４」という）に至る。アクション２７２ ０は、アクション２７０８と同様に、アクション２７０２で選択したテストを実 行する。選択したすべてのテストが実行された後、処理は単項演算子適用アクシ ョン２７２２（以下「アクション２７２２」という）に移行する。アクション２ ７２２は、分析中の演算子と、左辺オペランドに対応する引数情報ブロック２６ ００と、結果位置を指すポインタと、演算によって１が生成される場合に真理値 を保持するための条件変数とを指定してｖｉｍ基本評価ユニットを呼び出すこと により、単項演算子を評価する。単項演算を評価した後、処理は未決定関係判断 ２７３０（以下「判断２７３０」という）に移行する。 演算子が単項演算子ではない場合、処理は、演算子が２項演算子であるかどう かを判定する判断２７２４に移行する。演算子が２項演算子である場合、処理は テスト実行アクション２７２６（以下「アクション２７２６」という）に移行し 、そうではない場合、処理は判断２７３０に至る。アクション２７２６は、アク ション２７２０と同様に、アクション２７０２で選択したテストを実行する。テ ストが実行された後、処理は２項演算子適用アクション２７２８（以下「アクシ ョン２７２８」という）に移行する。 アクション２７２８は、分析中の演算子と、左辺オペランドに対応する引数情 報ブロック２６００と、右辺オペランドに対応する引数情報ブロック２６００と 、 結果位置を指すポインタと、演算によって１が生成される場合に真理値を保持す るための条件変数とを指定してｖｉｍ基本評価ユニットを呼び出すことにより、 ２項演算を評価する。２項演算を評価した後、処理は判断２７３０に移行する。 判断２７３０は、評価した演算が、「不明」値であると評価された関係演算で あったかどうかを確認するためのチェックを行う。モデル化メモリが実メモリの 正確な複製ではない場合の結果の１つは、モデル化メモリが３値真理論理を使用 することである。モデル化メモリ内の真理値は、「真」、「偽」、「不明」のい ずれかになる。「不明」条件は、真のメモリに関する知識が不完全であることに よる。演算の結果、「不明」条件が発生した場合、モデル化メモリの３値真理論 理を２値真理論理に変換しなければならない。判断２７３０が真になる場合、処 理は条件選択アクション２７３２（以下「アクション２７３２」という）に移行 する。アクション２７３２は、ＣＰＨ条件選択ユニットを呼び出すことによって 条件を選択する。ＣＰＨ条件選択ユニットについては以下に詳述する。選択が行 われると、アクション２７３２は、位置に対応する格納値ブロック１８００でフ ラグ「想定値フラグ」１８１０をオン（真）に設定する。処理は情報想定アクシ ョン２７３４（以下「アクション２７３４」という）に移行する。 アクション２７３２で選択が行われた場合、その選択の含意を示すためにモデ ル化メモリを必ず更新しなければならない。式の結果を選択することは、その式 で使用するオペランドに関する派生効果を有する。たとえば、以下のコード・サ ンプルを検討する。 変数ｉに関する情報が一切不明である場合、ゼロと同等であるｉを評価すると 、「不明」値が返されることになる。変数ｉと定数ゼロとを比較するための情報 がまったくないので、ｖｉｍ基本評価ユニットによって「不明」という値が返さ れる。ｉがゼロと同等であると想定するという選択が行われた場合、コード・パ ス に沿って今後のステートメントで変数ｉを一貫して使用するためには、ｉがゼロ と等しいことを反映するようにメモリを更新しなければならない。アクション２ ７３４は、モデル化メモリを適切に更新するためにｖｉｍ想定ユニットを呼び出 す。ｖｉｍ想定ユニットについては以下に詳述する。ｖｉｍ想定ユニットから戻 ると、論理流れ図２７００による処理、したがって、演算ユニットは終了する。 終了すると、処理制御は開始サイト制御に返される。 選択点を解決するための条件の選択は、ＣＰＨ条件選択ユニットによって行わ れる。ＣＰＨ条件選択ユニットについては論理流れ図３３００（第３３図）に示 す。処理は、選択実行判断３３０２（以下「判断３３０２」という）から始まる 。判断３３０２は、実行すべき選択がアクション１１０８で構築したパスの一部 に対応するかどうかを判定する。実行すべき選択がアクション１１０８で決定し たパス上の選択点によってすでに表されている場合、処理は選択アクション３３ ０４（以下「アクション３３０４」という）に移行する。アクション３３０４は アクション１１０８で構築したパスが指示する選択を行い、論理流れ図３３００ による処理、したがって、ＣＰＨ条件選択ユニットは終了する。 判断３３０２が偽を返す場合、いかなる選択も前もって決定されていないので 、処理はランダム選択アクション３３０６（以下「アクション３３０６」という ）に移行する。解決するためにＣＰＨ条件選択ユニットが呼び出された未解決の 選択点が選択点ノードに対応することに留意されたい。また、未解決の選択点に 関して可能な解決は、その選択点ノードから出る選択エッジに対応する。アクシ ョン３３０６は、未調査の選択エッジ間でランダム選択を行うことによって、結 果（選択）を抜き取る。選択が行われた後、処理はＣＰＨツリー更新アクション ３３０８（以下「アクション３３０８」という）に移行する。 アクション３３０８は、選択点ノードで選択したエッジ選択にマークを付ける ものである。この選択点ノードがすでにＣＰＨツリー上にあるものではない場合 、アクション３３０８はこれをツリーに挿入する。ＣＰＨツリーが更新された後 、論理流れ図３３００による処理、したがって、ＣＰＨ条件選択ユニットは終了 する。終了すると、処理制御は開始サイト制御に戻る。本発明の一実施形態では 、ＣＰＨ条件選択ユニットはルーチンによって行われる。マイクロフィッシュの 付 録Ａの実施形態では、「ｃｐｈ＿ｃｈｏｏｓｅ＿ｃｏｎｄｉｔｉｏｎ」というル ーチンがＣＰＨ条件選択ユニットの処理を実行する。 ｉｆ−ｅｌｓｅユニットは、ｉｆ−ｅｌｓｅステートメントを処理するもので ある。ｉｆ−ｅｌｓｅユニットについては論理流れ図２８００（第２８図）とし て詳細に示す。ｉｆ−ｅｌｓｅユニットの処理は、テスト式評価アクション２８ ０２（以下「アクション２８０２」という）から始まる。アクション２８０２は ｉｆ−ｅｌｓｅステートメントのテスト式を評価する。前述のように、式ユニッ ト（アクション２４０２）を呼び出すことにより、式を評価する。テスト式が評 価された後、処理は、テスト式の結果を検査するテスト式結果判断２８０４（以 下「判断２８０４」という）に移行する。テスト式が真であると評価された場合 、処理は、ｉｆ式を評価する「ｉｆ」式評価アクション２８０６（以下「アクシ ョン２８０６」という）に移行する。そうではない場合、処理は、偽式を評価す る「偽」式評価アクション２８０８（以下「アクション２８０８」という）に移 行する。アクション２８０６または２８０８後に、論理流れ図２８００の処理、 したがって、ｉｆ−ｅｌｓｅユニットは終了する。終了すると、ｉｆ−ｅｌｓｅ ユニットは開始サイト制御に制御を移転する。 ｗｈｉｌｅループ、ｄｏ ｗｈｉｌｅループ、ｆｏｒの各ユニットは、いずれ もループ実行ユニットを呼び出して、それぞれに対応するステートメントの処理 を実行する。３つのユニット間の唯一の違いは、ｆｏｒユニットはループ実行ユ ニットを呼び出す前に初期設定ステートメントを評価することである。ｆｏｒユ ニットは、処理制御をアクション１２０８に移転することにより、初期設定ステ ートメントを評価する。ループ実行ユニットについては論理流れ図２９００（第 ２９図）として詳細に示す。本発明の一実施形態では、ループ実行ユニットはル ーチンによって行われる。マイクロフィッシュの付録Ａの実施形態では、「ｅｘ ｅ＿ｌｏｏｐ」というルーチンがループ実行ユニットの処理を実行する。 ループ実行ユニットは、ループ・ステートメントを指し示すために実行コンテ キスト・ブロック２１００のフィールド「現行ステートメント」２１１０を更新 するステートメント・コンテキスト設定アクション２９０２から処理を始める。 処理は、現行ステートメントがｆｏｒまたはｗｈｉｌｅループであるかどうかを 判定するｆｏｒまたはｗｈｉｌｅループ判断２９０４に移行する。現行ステート メントがｆｏｒまたはｗｈｉｌｅループである場合、処理は、条件偽またはルー プ終了判断２９０６（以下「判断２９０６」という）に移行する。そうではない 場合、処理はループ未終了判断２９１０（以下「判断２９１０」という）に至る 。 判断２９０６は、式評価ユニットを呼び出すことにより、テスト条件式を評価 する。判断２９０６は、条件が偽であるかまたはループが終了したかどうかを判 定する。基本的にこれは、ループの本体より前にテストが評価されることを意味 する。ループ条件が偽であるかまたはループが終了した場合、処理は、ループ終 了フラグをオンにして、ループが完了したことを記憶するループ完了記憶アクシ ョン２９０８に移行する。そうではない場合、処理は判断２９１０に移行する。 判断２９１０は、ループ終了フラグに問い合わせて、ループが完了したかどう かを判定する。ループが完了していない場合、処理はアクション２９１２に移行 する。そうではない場合、処理はｄｏ ｗｈｉｌｅループ判断２９１８（以下「 判断２９１８」という）に移行する。アクション２９１２は、ループ本体内のす べてのステートメントを実行する。各ステートメントは、アクション１２０８を 呼び出すことによって実行される。ループ本体内の各ステートメントが実行され ると、処理は、現行ステートメントがｆｏｒループであるかどうかを判定するｆ ｏｒループ判断２９１４に移行する。現行ステートメントがｆｏｒループである 場合、処理は、式ユニットを呼び出すことにより増分式を評価するアクション２ ９１６に移行する。増分式が評価された後、または現行ステートメントがｆｏｒ ループではない場合、処理は判断２９１８に移行する。 判断２９１８は、現行ループがｄｏ ｗｈｉｌｅループであるかどうかを判定 する。現行ループがｄｏ ｗｈｉｌｅループである場合、処理は、式ユニットを 呼び出すことによりループ・テスト式を評価するテスト式評価アクション２９２ ０に移行する。ｄｏ ｗｈｉｌｅループの場合、テストはループの本体のあとで 評価される。最終テスト式が評価された後、または現行ループがｄｏ ｗｈｉｌ ｅループではない場合、論理流れ図２９００による処理、したがって、ループ実 行ユニットは終了する。ループ実行ユニットはループ本体の１回の実行だけをシ ミュレートする。終了すると、ループ実行ユニットは開始サイト制御に制御を返 す。 ｓｗｉｔｃｈユニットはｓｗｉｔｃｈステートメントを処理する。ｓｗｉｔｃ ｈユニットについては論理流れ図３０００（第３０ａ図、第３０ｂ図）に示す。 ｓｗｉｔｃｈユニットの処理は、ｓｗｉｔｃｈテスト式を評価するテスト式評価 アクション３００２から始まる。ｓｗｉｔｃｈテスト式は、式ユニットへの呼出 しにより評価される。制御は、他のｃａｓｅラベルを検査しなければならないか どうか、ならびにチェックすべきｃａｓｅラベルが残っているかどうかを判定す るチェックすべきｃａｓｅラベル判断３００４に移転する。依然としてｃａｓｅ ラベルを検査する必要性があり、依然としてチェックすべきものが複数ある場合 、処理は宣言ノード検索アクション３００６（以下「アクション３００６」とい う）に移行し、そうではない場合、処理はｃａｓｅ選択判断３０２８（以下「判 断３０２８」という）に移行する。 アクション３００６は、処理すべき次のｃａｓｅラベル用の宣言ノードを検索 する。処理は、アクション３００６から、ｃａｓｅラベルが記号テーブル内にあ るかどうかを判定する記号テーブル内ラベル判断３００８に移行する。ｃａｓｅ ラベルが記号テーブル内にある場合、処理はラベル集合構築アクション３０１２ （以下「アクション３０１２」という）に移行する。そうではない場合、処理は 、そのｃａｓｅラベルを記号テーブルに追加する記号テーブルへのラベル追加ア クション３０１０（以下「アクション３０１０」という）に移行する。 アクション３０１０は、そのｃａｓｅラベルを表すための記号テーブル項目１ ３００を作成する。新たに作成した記号テーブル項目１３００は記号テーブルに 格納される。処理は、アクション３０１０からアクション３０１２に移行する。 アクション３０１２は、そのｃａｓｅラベルをラベル集合に格納し、検討したす べてのｃａｓｅラベルの集合を構築する。処理は、アクション３０１２から、ｃ ａｓｅ内の第１のステートメントを指すポインタの集合を構築するステートメン ト集合構築アクション３０１４に移行する。検討した各ｃａｓｅラベルごとに１ つずつのポインタが存在する。ステートメント集合が更新された後、処理は式Ｃ ａｓｅラベル同等判断３０１６（以下「判断３０１６」という）に移行する。 判断３０１６は、ｓｗｉｃｈテスト式の結果とｃａｓｅラベルとを突き合わせ る。ｓｗｉｔｃｈテスト式の結果がｃａｓｅラベルと等しい場合、処理は現在の ｃａｓｅ選択アクション３０１８（以下「アクション３０１８」という）に移行 する。アクション３０１８は、現在のｃａｓｅラベルに対応するステートメント を実行すべきであることを示す。処理は、チェックすべきｃａｓｅラベルがこれ 以上ないことを示すためにフラグを設定する調査停止記憶アクション３０２０（ 以下「アクション３０２０」という）に移行する。処理はアクション３０２０か ら判断３００４に移行する。 ｓｗｉｔｃｈテスト式の結果が現在のｃａｓｅラベルと等しくなかった場合、 処理は、突合せが偽を返したかどうかを判定する突合せ結果偽判断３０２２に移 行する。突合せが偽を返した場合、処理は、偽の突合せの数をカウントする偽ｃ ａｓｅカウント・アクション３０２４（以下「アクション３０２４」という）に 移行する。ｓｗｉｔｃｈテスト式の結果とｃａｓｅラベルが等しいことを判定で きなかった場合、処理は、「不明」ｃａｓｅ集合構築アクション３０２６（以下 「アクション３０２６」という）に移行する。アクション３０２６は、判断３０ １６が結果を判定できなかったすべてのケースに対応するｃａｓｅラベルの集合 に現在のｃａｓｅラベルを追加する。処理は、アクション３０２４およびアクシ ョン３０２６から判断３００４に移行する。 ｃａｓｅ選択判断３０２８は、ｃａｓｅが選択されたかどうかを判定する。ｃ ａｓｅが選択された場合、処理は、次のｂｒｅａｋステートメントに到達するま で選択したｃａｓｅ内のステートメントを実行する次のｂｒｅａｋまでステート メントを実行するアクション３０３０に移行する。アクション１２０８を呼び出 すことにより、ステートメントを実行する。ｃａｓｅ内のすべてのステートメン トが実行されると、論理流れ図３０００による処理、したがって、ｓｗｉｔｃｈ ユニットは終了する。 ｃａｓｅがまだ選択されていない場合、処理は、偽ｃａｓｅの数がｓｗｉｔｃ ｈステートメント内のｃａｓｅの数に等しいかどうかを判定する偽カウントｃａ ｓｅ数同等判断３０３２に移行する。偽ｃａｓｅの数がｃａｓｅの数に等しい場 合、いずれのｃａｓｅラベルもｓｗｉｔｃｈテスト式結果と一致しないことを意 味し、処理はデフォルトｃａｓｅ内のステートメントを実行するデフォルトｃａ ｓｅ実行アクション３０３４（以下「アクション３０３４」という）に移行する 。アクション１２０８を呼び出すことにより、ステートメントを実行する。アク ション３０３４が完了すると、論理流れ図３０００による処理、したがって、ｓ ｗｉｔｃｈユニットは終了する。偽ｃａｓｅのカウントがｓｗｉｔｃｈステート メント内のｃａｓｅの数に等しくない場合、処理は不明ｃａｓｅ判断３０３６（ 以下「判断３０３６」という）に至る。 判断３０３６は、「不明」ｃａｓｅの集合内にラベルがあるかどうかを判定す る。「不明」ｃａｓｅ内にラベルがある場合、処理は不明ｃａｓｅとデフォルト ｃａｓｅの選択アクション３０３８（以下「アクション３０３８」という）に移 行する。そうではない場合、ｓｗｉｔｃｈユニット内の処理は終了する。 アクション３０３８は、「不明」ｃａｓｅとデフォルトｃａｓｅとから実行す べきｃａｓｅを選択する。アクション３０３８は、ＣＰＨ条件選択ユニット（第 ３３図）を呼び出すことにより、どのｃａｓｅを選択するかを判定する。ＣＰＨ 条件選択ユニットについては以下に詳述する。処理は、アクション３０３８から 、アクション３０３８で行った選択に基づいて情報を想定する情報想定アクショ ン３０４０（以下「アクション３０４０」という）に移行する。アクション３０ ４０は、演算ユニットのアクション２７３４（第２７図）と同様のものである。 アクション３０４０は、ｖｉｍ想定ユニットを呼び出して、アクション３０３８ で行った選択に基づいてモデル化メモリを更新する。 処理は、アクション３０４０から、次のｂｒｅａｋステートメントが検出され るまで選択したｃａｓｅ内のステートメントを実行するｂｒｅａｋまでのステー トメント実行アクション３０４２に移行する。ステートメントは、アクション１ ２０８への呼出しにより実行される。ステートメントが実行された後、論理流れ 図３０００による処理、したがって、ｓｗｉｔｃｈユニットは終了する。終了す ると、ｓｗｉｔｃｈユニットは開始サイト制御に処理制御を返す。 変数初期設定ユニットは、変数初期設定ステートメントを処理するものである 。変数初期設定ユニットについては論理流れ図３１００（第３１図）として示す 。変数初期設定ユニットの処理は、初期設定式を評価する初期設定評価アクショ ン３１０２から始まる。初期設定式は、式ユニットを呼び出すことによって評価 さ れる。初期設定式が評価された後、処理は、代入された値を受け取る変数用の宣 言ノードを突き止める、変数宣言ノード検出アクション３１０４（以下「アクシ ョン３１０４」という）に移行する。処理は、アクション３１０４から、演算ユ ニットを呼び出すことにより代入を評価する代入評価アクション３１０６に移行 する。演算ユニットは代入演算子を指定して呼び出される。代入が評価された後 、論理流れ図３１００による処理、したがって、変数初期設定ユニットは終了す る。 ｒｅｔｕｒｎユニットはｒｅｔｕｒｎステートメントを処理するものである。 ｒｅｔｕｒｎユニットについては論理流れ図３２００（第３２図）として示す。 ｒｅｔｕｒｎユニットは、ｒｅｔｕｒｎステートメントが式を有するかどうかを 判定するｒｅｔｕｒｎ式判断３２０２から処理を始める。ｒｅｔｕｒｎステート メントがｒｅｔｕｒｎ式を有していない場合、処理は式評価アクション３２０４ （以下「アクション３２０４」という）に移行する。そうではない場合、ｒｅｔ ｕｒｎユニットは終了する。 アクション３２０４は、式ユニットを呼び出すことにより式を評価する。ｒｅ ｔｕｒｎ式が評価された後、処理は、記号テーブル内の戻り値を探索する記号テ ーブル内の戻り値探索アクション３２０６（以下「アクション３２０６」という ）に移行する。アクション３２０６は、戻り値に対応する記号テーブル項目１３ ００からフィールド「記号位置」１３０６を検索する。処理は、ｒｅｔｕｒｎ記 号へのｒｅｔｕｒｎ式の代入を評価する代入評価アクション３２０８（以下「ア クション３２０８」という）に移行する。アクション３２０８は、変数初期設定 ユニットのアクション３１０６（第３１図）と同様のものである。代入は、代入 演算子を指定して演算ユニットを呼び出すことによって評価される。代入が評価 された後、論理流れ図３２００による処理、したがって、ｒｅｔｕｒｎユニット は終了する。 ラベル・ユニットは、ステートメントを導入するラベルを処理するものである 。ラベルとは、あとにコロン（「：」）が続く識別子である。「識別子」という 用語は、Ｂｒｉａｎ Ｗ．ＫｅｒｎｉｇｈａｎおよびＤｅｎｎｉｓ Ｍ．Ｒｉｔ ｃｈｉｅによるＴｈｅ Ｃ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅ、１７ ９（Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、１９７８年）に定義されているように、ここ で 使用する。一実施形態のラベル・ユニットは、フロースルー処理を実行するだけ であり、ラベル・ユニットは開始サイト制御に処理制御を移転する。 ｇｏｔｏユニットは、ｇｏｔｏステートメント内に指示されたステートメント （ｇｏｔｏ「ターゲット」ステートメント）に移行するように現行パスの制御の 流れを方向付けるものである。ｇｏｔｏユニットは、前述のようにｇｏｔｏパラ メータを真に設定する。ｇｏｔｏユニットは、ｇｏｔｏターゲット・ステートメ ントを表す現行構文解析ツリー構造３０４内のノードを指すポインタを検索し、 そのポインタを処理制御とともにアクション１２０８に転送する。制御がｇｏｔ ｏユニットに戻ると、処理は終了し、ｇｏｔｏユニットは開始サイト制御に制御 を移転する。本発明の一実施形態では、ｇｏｔｏユニットはルーチンによって実 現される。マイクロフィッシュの付録Ａの実施形態では、ｇｏｔｏユニット２３ は、「ｅｘｅ＿ｇｏｔｏ＿ｓｔａｔｅｍｅｎｔ」というルーチンによって実現さ れる。仮想イメージ・オブジェクト７０８ 仮想イメージ・オブジェクト７０８は、メモリ・モデルを構築、更新、および 検査する。仮想イメージ・オブジェクト７０８は、４つのユニット、すなわちメ モリ作成ユニット１５００（前述）、活力（ｖｉｍ）プリミティブ試験ユニット 、活力プリミティブ評価ユニット、および活力想定ユニットから構成される。仮 想イメージ・オブジェクト７０８のこれら４つのユニットは、メモリ・モデルに ついての試験および操作を実行し、こうした試験および操作が活力プリミティブ と呼ばれる。活力プリミティブは、メモリ・モデルの記憶された値に対して直接 実行されるわけではなく、フェッチ値と呼ばれる記憶された値の検索したコピー に対して実行される。フェッチ値の使用は、値を操作する前にレジスタ中に置く コンピュータ・プログラムと類似している。活力プリミティブのある特定の使用 についての情報は述語に集められる。述語は、後に自動モデル化に使用するため にログすることができる。活力プリミティブ、フェッチ値、述語、プリミティブ 評価ユニット、および想定ユニットについて、以下でさらに詳細に考察する。 本発明の１実施形態では、１８個の別個の活力プリミティブがある。活力プリ ミティブは、ｔｒｕｅ＿ａｓ＿ｃｏｎｄｉｔｉｏｎ、ｆａｌｓｅ＿ａｓ＿ｃｏｎ ｄｉｔｉｏｎ、ｉｎｉｔｉａｌｉｚｅｄ、ｖａｌｉｄ＿ｏｒ＿ｎｕｌｌ＿ｐｏｉ ｎｔｅｒ、ｖａｌｉｄ＿ｐｏｉｎｔｅｒ、ｉｎｖａｌｉｄ＿ｐｏｉｎｔｅｒ、ｖ ａｌｉｄ＿ｏｆｆｓｅｔ、ｃｏｍｐａｒａｂｌｅ、ｉｎｃｏｍｐａｒａｂｌｅ、 ｆｒｅｅａｂｌｅ、ｆｒｅｅｄ＿ｍｅｍｏｒｙ、ｎｅｗ＿ｍｅｍｏｒｙ、ｎｏｎ ＿ｚｅｒｏ、ｌｏｓｔ、ｉｎｔ＿ｔｏ＿ｆｌｏａｔ、ｆｌｏａｔ＿ｔｏ＿ｉｎｔ 、ｓｔａｔｅ＿ｅｑ、およびｓｔａｔｅ＿ｎｅである。活力プリミテイブ「ｔｒ ｕｅ＿ａｓ＿ｃｏｎｄｉｔｉｏｎ」は、指定された位置が「真」であると評価さ れるかどうかを示すよう活力ユニットに命令するものである。活力プリミティブ 「ｆａｌｓｅ＿ａｓ＿ｃｏｎｄｉｔｉｏｎ」は、指定された位置が「真」以外の 値であると評価されるかどうかを示すよう活力ユニットに命令するものである。 活力プリミティブ「ｉｎｉｔｉａｌｉｚｅｄ」は、指定された位置が初期値を含 むかどうかを示すよう活力ユニットに命令するものである。 活力プリミティブ「ｖａｌｉｄ＿ｏｒ＿ｎｕｌｌ−ｐｏｉｎｔｅｒ」は、指定 された位置が、モデル化されたメモリの現在使用されている部分を指すポインタ である有効ポインタ、または現在どこも指していない位置を指定するヌル・ポイ ンタのいずれかを含むかどうかを示すよう活力ユニットに命令するものである。 活力プリミティブ「ｖａｌｉｄ＿ｐｏｉｎｔｅｒ」は、指定された位置が、有効 ポインタ、すなわちモデル化されたメモリの現在使用されている部分を指すポイ ンタを含むかどうかを示すよう活力ユニットに命令するものである。活力プリミ ティブ「ｉｎｖａｌｉｄ＿ｐｏｉｎｔｅｒ」は、指定された位置が、モデル化さ れたメモリの現在使用されている部分を指すポインタを含まないかどうかを示す よう活力ユニットに命令するものである。 活力プリミティブ「ｖａｌｉｄ＿ｏｆｆｓｅｔ」は、指定された位置が、識別 された構造またはアレイ中への有効オフセットを含むかどうかを示すよう活力ユ ニットに命令するものである。活力プリミティブ「ｃｏｍｐａｒａｂｌｅ」は、 ２つの位置が同じチャンク１７００を指すかどうかを示すよう活力ユニットに命 令するものである。活力プリミティブ「ｉｎｃｏｍｐａｒａｂｌｅ」は、２つの 位置が同じチャンク１７００を指さないかどうかを示すよう活力ユニットに命令 するものである。活力プリミティブ「ｆｒｅｅａｂｌｅ」は、指定された位置が 解放可能なメモリを含むかどうかを示すよう活力ユニットに命令するものである 。活力プリミティブ「ｆｒｅｅｄ＿ｍｅｍｏｒｙ」は、指定された位置を解放す るよう活力ユニットに命令するものである。活力プリミティブ「ｎｅｗ＿ｍｅｍ ｏｒｙ」は、メモリ・モデル中で新しい位置を割り当てるよう活力ユニットに命 令するものである。 活力プリミティブ「ｎｏｎ＿ｚｅｒｏ」は、指定された位置がゼロ定数以外の 値を含むかどうかを示すよう活力ユニットに命令するものである。活力プリミテ ィブ「ｌｏｓｔ」は、指定された位置が失われたメモリとしてマークされている かどうかを示すよう活力ユニットに命令するものである。活力プリミティブ「ｉ ｎｔ＿ｔｏ＿ｆｌｏａｔ」は、指定された位置の値を、整数表示から浮動小数点 表示に変換するよう活力ユニットに命令するものである。活力プリミティブ「ｆ ｌｏａｔ＿ｔｏ＿ｉｎｔ」は、指定された位置の値を、浮動小数点表示から整数 表示に変換するよう活力ユニットに命令するものである。活力プリミティブ「ｓ ｔａｔｅ＿ｅｑ」は、指定された位置が、所与の状態と等しい状態にある資源を 表すかどうかを示すよう活力ユニットに命令するものである。最後に、活力プリ ミティブ「ｓｔａｔｅ＿ｎｅ」は、指定された位置が、所与の状態と等しくない 状態にある資源を表すかどうかを示すよう活力ユニットに命令するものである。 活力プリミティブを評価する際にはしばしば、ある位置によってモデル化され たメモリのタイプの特定の特徴を理解することが必要となる。様々なタイプのモ デル化されたメモリについては、「メモリ作成ユニット１５００」の見出しで既 に考察した。様々なタイプのモデル化されたメモリのそれぞれについて、対応す るメモリ情報ブロック３４００（第３４図）が存在する。メモリ情報ブロック３ ４００は、対応するメモリ・タイプの特定の特徴を識別する。メモリ情報ブロッ ク３４００は下記のフィールドを含む。「メモリ・タイプ」３４０２、「印刷可 能メモリ名」３４０４、「定数フラグ」３４０６、「デリファレンス・タイプ」 ３４０８、「開始時初期化フラグ」３４１０、「開始時有効フラグ」３４１２、 「ロスト・フラグ」３４１４、「自由許可フラグ」３４１６、「フリー・エラー ・コード」３４１８、「資源フラグ」３４２０、「ログ試験フラグ」３４２２、 「初期化」３４２４、「有効」３４２６、および「ヌル」３４２８。 フィールド「メモリ・タイプ」３４０２は、瞬間メモリ・タイプ情報ブロック ３４００（瞬間メモリ・タイプとも呼ばれる）が表すメモリのタイプを識別する 。フィールド「印刷可能メモリ名」３４０４は、印刷可能なフォーマットの瞬間 メモリ・タイプの名前を指定する。フィールド「印刷可能メモリ名」３４０４は 、エラー・メッセージの生成に使用される。フラグ「定数フラグ」３４０６は、 瞬間メモリ・タイプが定数であるときにオンにセットされる。メモリ・タイプが 定数である場合には、そのタイプの位置は割当てを受けることができない。フィ ールド「デリファレンス・タイプ」３４０８は、適用可能であるときに、瞬間メ モリ・タイプが指すメモリ・タイプを示す。 フラグ「開始時初期化フラグ」３４１０は瞬間メモリ・タイプが初期化された ときにオンにセットされる。フラグ「開始時有効フラグ」３４１２は、瞬間メモ リ・タイプが有効ポインタであるときにオンにセットされる。フラグ「ロスト・ フラグ」３４１４は、瞬間メモリ・タイプが失われる可能性があるときにオンに セットされる。フラグ「自由許可フラグ」３４１６は、瞬間メモリ・タイプを解 放することができるときにオンにセットされる。フィールド「自由エラー・コー ド」３４１８は、適用可能である場合には、瞬間メモリ・タイプを解放する際に 生成されるエラー・コードを指定する。 フラグ「資源フラグ」３４２０は、瞬間メモリ・タイプが資源を参照するとき にオンにセットされる。フラグ「ログ試験フラグ」３４２２は、瞬間メモリ・タ イプの位置に対して行われる試験をログしなければならないときにオンにセット される。フィールド「初期化」３４２４は、ある位置を、初期化されたものであ るとして瞬間メモリ・タイプから識別することができるかどうかを指定する。フ ィールド「有効」３４２６は、ある位置を、有効であるとして瞬間メモリ・タイ プから識別することができるかどうかを指定する。フィールド「ヌル」３４２８ は、ある位置を、ヌルであるものとして瞬間メモリ・タイプから識別することが できるかどうかを指定する。 フェッチ値は、記憶された値に含まれる値の作業用コピーとして使用される。 フェッチ値をフェッチ値ブロック３５００で説明する。フェッチ値ブロック３５ ００は、第３５図に示してある。フェッチ値ブロック３５００は下記のフィール ドを含む。「バイト数」３５０２、「正確な値が既知のフラグ」３５０４、「正 確値ポインタ」３５０６、「述語集合ポインタ」３５０８、「値の形式」３５１ ０、「実数の値」３５１２、「無符号整数の値」３５１４、「資源タイプ」３５ １６、「資源状態」３５１８、「初期化フラグ」３５２０、「有効ポインタ」３ ５２２、「非ゼロ・フラグ」３５２４、「新規述語フラグ」３５２６、「変更フ ラグ」３５２８、「想定フラグ」３５３０、「ｓｖｓポインタ」３５３２、「ｓ ｖｓオフセット」３５３４、「位置からのフラグ」３５３６、「位置」３５３８ 、「チャンク起点」３５４０、「メモリ・タイプ」３５４２、「ｓｖサブセット ・ポインタ」３５４４、「式ポインタ」３５４６、および「デリファレンス・フ ラグ」３５４８。 フィールド「バイト数」３５０２は、記述される値が表すバイト数を指定する 。フラグ「正確な値が既知のフラグ」３５０４は、記述される値が完全に既知で あるときにオンにセットされる。フィールド「正確値ポインタ」は、適用可能で あるときに、正確な値を含むバイト・アレイを指す。指されるバイト・アレイの サイズは、フィールド「バイト数」３５０２に含まれる数と等しい。フィールド 「述語集合ポインタ」３５０８は、瞬間フェッチ値に適用される全ての述語の集 合を指す。フィールド「値の形式」３５１０は、記述される値の形式のタイプを 示す。フィールド「実数の値」３５１２は、フィールド「値の形式」３５１０が 実数値を示すときに、記述される値を実数形式で指定する。フィールド「無符号 整数の値」３５１４は、フィールド「値の形式」３５１０が実数値以外を示すと きに、記述される値を整数形式で指定する。 フィールド「資源タイプ」３５１６は、適用可能である場合には、記述される 値に関連した資源のタイプを示す。フィールド「資源状態」３５１８は、適用可 能である場合には、記述される値に関連した資源の状態を示す。フラグ「初期化 フラグ」３５２０は、記述される値が初期化されたときにオンにセットされる。 フィールド「有効ポインタ」３５２２は、フェッチ値が有効ポインタであるかど うかを示す。フラグ「非ゼロ・フラグ」３５２４は、真であるときには、フェッ チ値がゼロ定数でないことを知らせる。フラグ「新規述語フラグ」３５２６は、 「述語集合ポインタ」３５０８が指す述語の集合に、任意の述語が追加されてい るかどうかを示す。フラグ「変更フラグ」３５２８は、フェッチ値が任意の活力 プリミティブによって変更されているかどうかを知らせる。フェッチ値は、活力 プリミティブによって変更されているときには、メモリ・モデルに戻して記憶し なければならない。フラグ「想定フラグ」３５３０は、フェッチ値が活力プリミ ティブによって想定されているかどうかを示す。フェッチ値は、活力プリミティ ブによって想定されているときには、対応する記憶された値に上書きしなければ ならない。 フィールド「ｓｖｓポインタ」３５３２は、フェッチ値の発生元となる、記憶 された値のセットを指す。フィールド「ｓｖｓオフセット」３５３４は、フィー ルド「ｓｖｓポインタ」３５３２が指す記憶された値のセット中のフェッチ値の 開始オフセットを含む。フラグ「位置からのフラグ」は、フェッチ値の内容がモ デル化されたメモリの位置から来たものであるかどうかを示す。フィールド「位 置」３５３８は、フェッチ値の発生元となるモデル化されたメモリ中の位置を指 す。フィールド「チャンク起点」３５４０は、フィールド「ｓｖｓポインタ」３ ５３２が指す記憶された値のセットを指すチャンク１７００によって指される起 点コンテキスト構造１６００を指す。フィールド「メモリ・タイプ」３５４２は 、どのような種類のメモリがフェッチ値によって使用されるかを指定する。 フィールド「ｓｖサブセット・ポインタ」３５４４は、フィールド「ｓｖｓポ インタ」３５３２が指す記憶された値のセットに含まれる記憶された値のサブセ ットを含む集合を指す。フィールド「式ポインタ」３５４６は、フェッチ値を含 む式を表す現在の構文解析ツリー構造３０４中のノードを指すポインタを含む。 フラグ「デリファレンス・フラグ」３５４８は、フェッチ値が実際に、フィール ド「式ポインタ」３５４６が示す式中の値のデリファレンスであるかどうかを示 す。 述語は、左側オペランドおよび場合によっては右側オペランドに適用される活 カプリミティブの特定の適用についての情報を記憶している。述語は、述語ブロ ック３６００で表される。述語ブロック３６００は下記のフィールドを含む。「 プリミティブ」３６０２、「無符号オペランド・フラグ」３６０４、「ｓｖｓ ポインタ」３６０６、「ｓｖオフセット」３６０８、「ｓｖカウント」３６１０ 、「引数」３６１２、「引数オフセット」３６１４、「引数長さ」３６１６、「 資源タイプ」３６１８、および「資源状態」３６２０。 フィールド「プリミティブ」３６０２は、この述語が記録する活力プリミティ ブのタイプを指定する。フラグ「無符号オペランド・フラグ」３６０４は、この 述語が表す活力プリミティブ（表された活力プリミティブと呼ぶ）が無符号オペ ランドに適用されたかどうかを示す。フィールド「ｓｖｓポインタ」３６０６は 、表された活力プリミティブが適用される値に対応する記憶された値のセットを 指す。フィールド「ｓｖオフセット」３６０８は、表された活力プリミティブが 適用される、「ｓｖｓポインタ」３６０６が指す記憶された値のセットの中の、 第１の記憶された値のオフセットを指定する。フィールド「ｓｖカウント」３６ ０８は、表された活力プリミティブが適用される記憶された値の数を指定する。 フィールド「引数」３６１２は、適用可能である場合には、述語の右側オペラン ドを指す。フィールド「引数オフセット」３６１４は、右側オペランドについて の第１の記憶された値を指す。フィールド「引数長さ」３６１２は、右側オペラ ンドを表すために使用される記憶された値の数を指定する。フィールド「資源タ イプ」３６１８は、活力プリミティブが資源プリミティブであるときに、資源の タイプを示す。フィールド「資源状態」３６２０は、活力プリミティブが資源プ リミティブであるときに、資源状態を示す。 活力プリミティブ試験ユニットは、メモリ・モデルの内容に対して試験を実行 する。付録Ｄは、活力プリミティブ試験ユニットを実施するために使用される１ 実施形態の疑似コードを含む。活力プリミティブ評価ユニットは、メモリ・モデ ルを更新して、指定されたオペレーションを評価した結果を反映する。付録Ｄは 、活力プリミティブ評価ユニットを実施するために使用される１実施形態の疑似 コードを含む。活力想定ユニットは、メモリ・モデルを更新して、未解決な選択 点をＣＰＨ選択条件ユニットで解決した結果を反映する。付録Ｄは、活力想定ユ ニットを実施するために使用される１実施形態の疑似コードを含む。障害インジケータ・オブジェクト７１２ 障害インジケータ・オブジェクト７１２は、障害インジケータ１０６を生成し て、分析器２０２が検出したプログラミング・エラーを報告する。障害インジケ ータ・オブジェクト７１２の処理は、エラー生成ユニットによって実行される。 エラー生成ユニットは、論理流れ図３７００（第３７図）として詳細に示してあ る。第３７図の実施形態では、障害インジケータ１０６はエラー・メッセージの 形になっている。 エラー生成ユニット中の処理は、検出されたプログラミング・エラーがメモリ または資源の漏れであるかどうかを決定する漏れエラー判断３７０２（以下「判 断３７０２」とする）から開始する。エラーが漏れである場合には、処理制御は 、パス終了タイプを決定する処置３７０４（以下「処置３７０４」とする）に移 ることになり、そうでない場合には、処理制御は、ｍａｉｎ関数中のローカル・ エラーの判断３７１０（以下「判断３７１０」とする）に移る。 処置３７０４は、漏れを生じるパスがどのようにして終了したかを決定する。 パスは３通りの方法、すなわち出口、ロングジャンプ、またはリターンの１つで 終了することができる。パス終了のタイプが発見された後で、処理制御は、抑制 終了タイプの判断３７０６（以下「判断３７０６」とする）に移る。判断３７０ ６は、構成オプションが、漏れを生じたパスの方法で、終了したパスの漏れエラ ーを抑制するようにセットされているかどうかを決定する。このような構成オプ ションがセットされている場合には、処理制御は、論理流れ図３７００に従って 処理を終了するリターン３７０８に移る。したがって、エラー生成ユニットは、 エラー・メッセージを生み出すことなく終了する。漏れエラーの報告を行う構成 オプションは、「ｌｅａｋｓ＿ｏｎ＿ｅｘｉｔ」、「ｌｅａｋｓ＿ｏｎ＿ｌｏｎ ｇｊｕｍｐ」、および「ｌｅａｋｓ＿ｏｎ＿ｒｅｔｕｒｎ」である。構成オプシ ョンについてのこれ以上の情報は、付録Ｂに与える。構成オプションが漏れエラ ー・メッセージを抑制するようにセットされていない場合には、処理は判断３７ １０に移る。 判断３７１０は、現在の関数名が「ｍａｉｎ」であるかどうか、またこの関数 が、「ｍａｉｎ」関数にローカルなメモリにポインタを戻しているかどうかを決 定する。このような（判断３７１０が真であると決定した）場合には、処理は、 論理流れ図３７００に従って処理を終了するリターン３７１２に移る。したがっ て、エラー生成ユニットは、エラー・メッセージを生み出すことなく終了する。 判断３７１０が偽であると決定したときには、処理制御は、コンテキスト情報を 得る処置３７１４（以下「処置３７１４」とする）に移る。 処置３７１４は、生成されたエラー・メッセージに記入するために使用するこ とになるコンテキスト情報を収集する。コンテキスト情報により、ユーザは、コ ード中のプログラミング・エラーを突き止めることができる。処置３７１４は、 障害のある関数を含むファイルのファイル名、および関数内のエラーが検出され た行番号を決定する。処置３７１４は、エラーのある関数の名前、エラーが発生 したパスの番号、およびエラーを含む式も収集する。関数のエミュレーション中 にエラーが発生した場合には、処置３７１４は、エミュレートした関数の名前と 、エミュレートした関数を含むファイルの名前と、エミュレートされた関数中の エラーが検出された行に対応するそのファイル中の行番号を収集する。処置３７ １４でのデータ収集が完了した後で、処理は、構成オプション抑制判断３７１８ （以下「判断３７１８」とする）に移る。 判断３７１８は、検出されたエラーの報告を防止する構成オプションが使用可 能になっているかどうかを決定する。このような構成オプションが指定されてい る（判断３７１８が真であると決定した）ときには、処理は、リターン３７２０ に移り、論理流れ図３７００に従って処理を終了する。したがって、エラー生成 ユニットは、エラー・メッセージを生み出すことなく終了する。関連のある構成 オプションは、特定のエラー・メッセージのみの生成を指示する「報告」、およ び特定のエラー・メッセージの抑制を指示する「抑制」である。特定の構成オプ ションについてのこれ以上の情報は、付録Ｂに与える。判断３７１８が偽である と決定したときには、処理制御は重複エラー判断３７２２（以下「判断３７２２ 」とする）に移る。 判断３７２２は、検出されたエラーが以前に報告されたエラーとの重複である かどうかを決定する。エラーは、異なる３つの形で重複エラーに分類される。第 １に、エラーは、以前のエラーが同じファイル名および文中に発生した場合に重 複となる。第２に、エラーは、以前に報告されたミッシング・モデルについての ミッシング・モデル・エラーである場合に重複となる。第３に、エラーは、検出 されたエラーを引き起こした記憶された値のセットが、以前に報告されたエラー を引き起こしたものと同じ記憶された値のセットである場合に重複となる。検出 されたエラーが重複エラーである（判断３７２２が真であると決定した）場合に は、処理は、リターン３７２４に移り、論理流れ図３７００に従って処理を終了 する。したがって、エラー生成ユニットは、エラー・メッセージを生み出すこと なく終了する。判断３７２２が偽であると決定したときには、処理制御はエラー 報告処置３７２６（以下「処置３７２６」とする）に移る。 処置３７２６は、検出されたエラーのタイプに対応するエラー・メッセージを 印刷する。印刷する前に、エラー・メッセージには、処置３７１４で収集された コンテキスト情報が記入される。エラー・メッセージが印刷された後で、論理流 れ図３７００による処理、したがってエラー生成ユニットは終了する。終了する と、エラー生成ユニットは、制御が発生したサイトに処理制御を戻す。自動モデル化 概説 モデル１１８は、対応する関数の動作を概略的に表すものでる。モデル１１８ は、関数の外部に可視の動作、すなわち関数の呼出し元に見える動作のみを含む 。 別の関数を呼び出す関数を分析するときには、分析器２０２は、呼び出される 関数のモデルを使用してその動作を決定する。これにより分析は非常に簡単にな り、速度も上がり、分析器２０２は、呼び出される関数のソース・コードを必要 としなくなり、その分析に時間をかける必要もなくなる。 モデルは、分析器２０２によって自動的に生成される。分析器は、関数を分析 する際にその関数が何を行うかを記憶し、その関数の分析が完了するときに、そ の関数のモデル１１８を構築する。 分析器は、付録Ｇに記載する特殊なモデル化言語でモデル１１８を読み取り、 これに書き込む。ユーザがその言語でモデル１１８に書き込むこともできるが、 これは、ソースのない、したがって分析し、自動的にモデル化することができな い関数について行われる。モデル化の概念 エクスターン、制約、結果、アウトカム、および保護の５つの基本的なモデル 化の概念がある。 エクスターンは、単なる外側から見ることのできる関数中の変数である。具体 的に言うと、これらはパラメータ変数、大域変数、および静的変数である。モデ ル１１８は外部から可視の動作しかカプセル化しないので、これらはモデル１１ ８中に現れることができる変数のみとなる。 制約は、関数が入力されたときに真とならなければならない条件である。例え ばそのパラメータの１つが有効ポインタであると関数が想定している場合には、 関数のモデル１１８はそれを必要とする制約を含むことになる。制約は、関数が 呼び出され、モデル１１８が評価されるときに試験されることになり、その制約 が当てはまらない場合には、分析器２０２がエラーを報告することになる。 制約とは対照的に、結果は、関数が戻したときに真となる条件である。例えば 関数がゼロを戻した場合には、それが結果になることになる。次いで結果は、分 析器２０２で後続の分析に使用される。例えば、呼び出された関数の戻し値がそ の後で変数に割り当てられた場合には、呼び出された関数のモデル１１８が戻す 結果は分析中の変数に割り当てられることになる。 アウトカムは、関数が分割されたケースである。ほとんどの関数は条件（ｉｆ −ｔｈｅｎ、ｓｗｉｔｃｈ、ｆｏｒ ｌｏｏｐなど）を含み、この条件付き実行 はモデル１１８の中で表されなければならず、そうでなければ、モデル化された あらゆる関数は呼び出されるたびに同じことを行うことになる。これに対して、 モデル１１８はそれらがモデル化した関数より単純になる必要があり、そうでな ければ、それらは関数自体より速く評価することができないことになる。関数は 、それが戻す値に基づいてケースに分割され、これらの各ケースがアウトカムと なる。例えば関数ｍａｌｌｏｃは、それが成功した場合にはポインタを、失敗し た場合には０（ヌル）を、割り振られたメモリに戻す。ｍａｌｌｏｃのモデルは ２つのアウトカムを有する。より一般的には、分析器２０２は戻し値を以下のケ ースに分割する。 ・関数が０を戻す ・関数が１を戻す ・関数が−１を戻す ・関数が上記３つのうちの１つに制限されない値を戻す ・戻し値が未知である ・関数が値を戻さない（ボイド関数の場合） ・関数がロングジャンプする ・関数が終了する これらのアウトカム・タイプは、それらが速度（いくつかのアウトカム・タイプ ）と情報の完全さ（多くのアウトカム・タイプ）の間の妥当なトレードオフを表 すことから選択した。 モデルが複数のアウトカムを有するときには、分析器２０２は、どのアウトカ ムを使用するか選択しなければならない。この選択はしばしば入力値に基づいて 行われる。保護は、こうした選択を表すために使用される機構である。例えば、 以下の関数は、１を戻す場合と０を戻す場合の、２つのアウトカムを有する。 この関数は、パラメータが０である場合には１しか戻さず、パラメータが０でな い場合には０しか戻さない。各アウトカムは適当な条件を具体化した保護を有す ることになる。 保護は制約と全く同じ形をしているが、それらの意味は異なる。制約は「この アウトカムが選択され、その制約の条件が当てはまらない場合に、エラーを報告 する」という意味であるが、保護は、「その保護の条件が当てはまらない場合に は、このアウトカムを選択してはならない」という意味となる。条件を評価する ことができない場合（例えば上記の値１が未知である場合）には、ある条件が想 定され（ここではｉの値）、あるアウトカムが選択される。自動モデラ 自動モデラは、関数を分析する際にモデル１１８を構築する。現在の関数を介 した各パスが終了するとき、処置１２１６中に、メモリ・モデル中の構造を走査 し、制約および保護を決定する各外部について実行された試験と、結果を決定す る各外部に対して行われた変更（割当てなど）とを決定する。これらの制約およ び結果はアウトカムにパッケージされる。現在の関数についての分析が終了する とき、処置１１１４内で、全ての個別のパスのアウトカムを操作し、無関係のオ ペレーションを除去し、重複したアウトカムを削除する。次いで個別のアウトカ ムを、エクスターンのリストと共に現在の関数のモデルにパッケージする。付録 Ｅは、自動モデラを実施するために使用される一実施形態の擬似コードを含む。 マイクロフィッシュの付録Ａのコンピュータ・プログラムは、一実施形態では 、ＵＮＩＸ Ｓｏｌａｒｉｓ ２．５^(R)オペレーティング・システムと、米国 カリフォルニア州、Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔ ｅｍｓから市販されているＳｕｎ ＳＰＡＲＣｓｔａｔｉｏｎ^TM５などのワーク ステーションを備えたＳＰＡＲＣｗｏｒｋｓ^TM３．０．１コンパイラおよびリン カとを使用してコンパイルおよびリンクされた。第２の実施形態では、マイクロ フィッシュの付録Ａのコンピュータ・プログラムは、米国Ｗａｓｈｉｎｇｔｏｎ 州、ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販さ れている、やはりＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販されて いるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ^TM３．５．１を使用してパーソ ナル・コンピュータ上で使用することができる、Ｍｉｃｒｏｓｏｆｔ Ｖｉｓｕ ａｌ Ｃ＋＋ ４．０が統合された開発環境を使用してコンパイルおよびリンク された。このようなパーソナル・コンピュータとしては、米国サウスダコタ州、 Ｎｏｒｔｈ Ｓｉｏｕｘ ＣｉｔｙのＧａｔｅｗａｙ ２０００ Ｉｎｃ．から 市販されているＧａｔｅｗａｙ Ｇ６−２０００がある。マイクロフィッシュの 付録Ａのコンピュータ・プログラムが適合する特定のコンピュータ言語、および マイ クロフィッシュの付録Ａのコンピュータ・プログラムによって規定されるコンピ ュータ・プロセスが実行されるコンピュータ・システムは、本発明の重要な面で はない。本発明の開示に鑑みて、当業者なら、様々なコンピュータ言語および／ または様々なコンピュータ・システムを使用して本発明を実施することができる 。 上記の記述は単なる例示であり、制限的なものではない。例えば、開示の実施 形態ではＣコンピュータ言語に従って関数を分析するが、本発明の原理は、上記 のものも含めて、ただしそれらに制限されることなく、その他のコンピュータ命 令プロトコルに適用することができる。本発明は下記の請求の範囲によってのみ 制限される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ， ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，Ｆ Ｉ，ＧＢ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ， ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，Ｍ Ｘ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ， ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 ウイルバー，リチャード・イー アメリカ合衆国・95008・カリフォルニア 州・キャンベル・ポップラー アヴェニ ュ・175 (72)発明者 メジャー―ディグナン，デビイ アメリカ合衆国・95118・カリフォルニア 州・サン ホゼ・パイン フォーレスト プレイス・4828 (72)発明者 シェラフ，デヴィッド・ジョン アメリカ合衆国・94602・カリフォルニア 州・オークランド・ウオーターハウス ロ ード・4007 【要約の続き】 のために、メモリ・モデルの操作を記述する情報をログ する。構造メモリ・モデル中の無効条件が検出され、報 告される。各パスの分析の後で、自動モデル化のために ログした情報を操作し、そのパスについてのアウトカム を構築する。個別のパスの分析が完了した後で、様々な アウトカムを処理し、重複を除去し、分析中のコンピュ ータ・プログラムを表す外部動作モデルを生成する。

Claims (1)

1. 【特許請求の範囲】 １．１つまたは複数のステートメントを含む少なくとも１つの関数を含むコンピ ュータ・プログラムの実行をシミュレートして、前記コンピュータ・プログラム 中のプログラム・エラーを検出する方法であって、 前記コンピュータ・プログラムの表現を検索する段階と、 前記ステートメントの第１列を含む第１制御フロー・パスを、前記関数を通し てトラバースする段階とを含み、前記トラバース段階が、 前記第１制御フロー・パスにわたって前記関数について第１構造メモリ・モ デルを維持する段階、 前記第１構造メモリ・モデルを操作して前記ステートメントの前記第１列の 実行をシミュレートする段階、 前記第１構造メモリ・モデル中の無効条件を検出する段階、および 前記第１構造メモリ・モデル中の前記無効条件を報告する段階 を含む方法。 ２．前記コンピュータ・プログラムの前記表現が内部フォーマット構造である請 求項１に記載の方法。 ３．前記コンピュータ・プログラムによって規定される全ての前記関数を識別す る段階と、 前記コンピュータ・プログラムによって規定される前記関数のリストを、関数 呼出し順序に基づいて順序づける段階と、 前記コンピュータ・プログラムによって規定される前記関数のリストの前記順 序づけに基づいて、前記コンピュータ・プログラムの分析をスケジューリングす る段階と をさらに含む請求項１に記載の方法。 ４．構成制御コマンドを受け入れる段階と、 前記構成制御コマンドに基づいて前記コンピュータ・プログラムの分析を修正 する段階と をさらに含む請求項１に記載の方法。 ５．指定された関数用の第２構成制御コマンドを受け入れる段階と、 前記第２構成制御コマンドに基づいて前記の指定された関数の分析を修正する 段階と をさらに含む請求項４に記載の方法。 ６．指定されたステートメント用の第３構成制御コマンドを受け入れる段階と、 前記第３構成制御コマンドに基づいて前記の指定されたステートメントの分析 を修正する段階と をさらに含む請求項５に記載の方法。 ７．第１制御フロー・パスを前記関数を通してトラバースする前記段階が、 前記第１制御フロー・パス中で未解決な選択点を識別する段階と、 前記未解決な選択点を、前記選択点の解決の可能性のそれぞれに対するエッジ を含むツリー内のノードで表す段階と、 第１の未選択のエッジを無作為に選択して第１選択を決定することにより、前 記未解決な選択点を解決する段階と をさらに含む請求項１に記載の方法。 ８．前記未解決な選択点を解決する前記段階が、 前記第１選択の履歴を維持する段階と、 第２の未選択の前記エッジを無作為に選択して第２選択を決定する段階とをさ らに含む請求項７に記載の方法。 ９．第１制御フロー・パスを前記関数を通してトラバースする前記段階が、 前記第１構造メモリ・モデルを更新して、前記未解決な選択点を解決する前記 段階を反映する段階と、 をさらに含む請求項７に記載の方法。 １０．前記コンピュータ・プログラムの前記表現を分析して関数呼出しを識別す る段階と、 前記関数呼出しに対応する呼び出された関数の外部動作モデルを突き止める段 階と、 前記関数呼出しに対応する呼び出された関数の前記外部動作モデルを検索する 段階とをさらに含む請求項１に記載の方法であって、前記第１構造メモリ・モデ ルを操作して前記ステートメントの前記第１列の実行をシミュレートする前記段 階が、 前記関数呼出しに対応する呼び出された関数の前記外部動作モデルの実行を介 して前記関数呼出しの実行をエミュレートする段階をさらに含む方法。 １１．前記第１構造メモリ・モデル中の前記無効条件が、メモリの初期化されて いない部分を知らせる請求項１に記載の方法。 １２．前記第１構造メモリ・モデル中の前記無効条件が、無効ポインタを知らせ る請求項１に記載の方法。 １３．前記第１構造メモリ・モデル中の前記無効条件が、ゼロ因子を知らせる請 求項１に記載の方法。 １４．前記第１構造メモリ・モデルを操作する前記段階を記述する情報をログし て、第１ログ・データを生成する段階 をさらに含む請求項１に記載の方法。 １５．前記関数を自動モデル化して前記関数に対応する外部動作モデルを生成す る段階をさらに含む請求項１４に記載の方法であって、前記自動モデル化段階が 、 前記第１ログ・データを走査して、前記第１制御フロー・パスについての第１ のアウトカムを生み出す段階を含む方法。 １６．前記関数を自動モデル化する前記段階が、 前記第１ログ・データを操作して、前記関数のエクスターンを識別する段階を さらに含む請求項１５に記載の方法。 １７．前記関数を自動モデル化する前記段階が、 前記第１構造メモリ・モデルを操作する前記段階を記述する情報をログする前 記段階の前に、前記第１構造メモリ・モデルへの１つまたは複数のリンクを含む 記号表を順序づけする段階をさらに含む請求項１５に記載の方法。 １８．前記ステートメントの第２列を含む第２制御フロー・パスを、前記関数を 通してトラバースする段階と、 前記第２構造メモリ・モデルを操作する前記段階を記述する情報をログして、 第２ログ・データを生成する段階と をさらに含み、前記トラバース段階が、 前記第２制御フロー・パスにわたって前記関数について第２構造メモリ・モ デルを維持する段階、および 前記第２構造メモリ・モデルを操作して前記ステートメントの前記第２列の 実行をシミュレートする段階を含み、 前記関数を自動モデル化して前記関数に対応する外部動作モデルを生成する段 階が、 前記第２ログ・データを走査して、前記第２制御フロー・パスについての第 ２のアウトカムを生み出す段階と、 前記第１のアウトカムおよび前記第２のアウトカムの間の重複を解消して、 １つまたは複数の残りのアウトカムを生成する段階と、 前記残りのアウトカムおよび前記エクスターンを、前記関数に対応する前記 外部動作モデルにパッケージする段階と を含む請求項１６記載の方法。 １９．前記コンピュータ・プログラムが第１関数である請求項１８に記載の方法 。 ２０．前記第１関数が第２コンピュータ・プログラムの一部分であり、前記関数 を自動モデル化する前記段階で生成された前記外部動作モデルが、前記第２コン ピュータ・プログラムの分析において前記第１関数をエミュレートするために使 用される請求項１９に記載の方法。 ２１．前記第１構造メモリ・モデル中の前記無効条件を報告する前記段階が、 前記無効条件が重複であると決定する段階と、 前記無効条件の報告を抑制する段階と をさらに含む請求項１に記載の方法。 ２２．前記第１構造メモリ・モデル中の前記無効条件を報告する前記段階が、 前記構成制御コマンド、前記第２構成制御コマンド、および前記第３構成制御 コマンドのうち１つが前記無効条件の抑制をオーダーすると決定する段階と、 前記無効条件の報告を抑制する段階と をさらに含む請求項６に記載の方法。 ２３．ゼロ個のステートメントを含む少なくとも１つの関数を含むコンピュータ ・プログラムの実行をシミュレートして、前記コンピュータ・プログラム中のプ ログラム・エラーを検出する方法であって、 前記コンピュータ・プログラムの表現を検索する段階と、 ゼロ個のステートメントを含む制御フロー・パスを前記関数を通してトラバー スする段階と、 前記関数を記述する情報をログしてログ・データを生成する段階と、 前記関数を自動モデル化して前記関数に対応する外部動作モデルを生成する段 階と を含み、前記トラバース段階が、 前記制御フロー・パスにわたって前記関数について構造メモリ・モデルを維 持する段階を含み、 前記自動モデル化段階が、 前記ログ・データを走査して前記制御フロー・パスについてのアウトカムを 生み出す段階を含む方法。 ２４．前記関数を自動モデル化する前記段階が、 前記ログ・データを走査して前記関数のエクスターンを識別する段階 をさらに含む請求項２４に記載の方法。 ２５．１つまたは複数のステートメントを含むコンピュータ・プログラムの実行 をシミュレートして、前記コンピュータ・プログラム中のプログラム・エラーを 検出する方法であって、 前記コンピュータ・プログラムの表現を検索する段階と、 前記ステートメントの第１列を含む第１制御フロー・パスを、前記コンピュー タ・プログラムを通してトラバースする段階とを含み、前記トラバース段階が、 前記第１制御フロー・パスにわたって前記コンピュータ・プログラムについ て第１構造メモリ・モデルを維持する段階、 前記第１構造メモリ・モデルを操作して前記ステートメントの前記第１列の 実行をシミュレートする段階、 前記第１構造メモリ・モデル中の無効条件を検出する段階、および 前記第１構造メモリ・モデル中の前記無効条件を報告する段階 を含む方法。 ２６．前記コンピュータ・プログラムの前記表現が内部フォーマット構造である 請求項２５に記載の方法。 ２７．第１制御フロー・パスを前記コンピュータ・プログラムを介してトラバー スする前記段階が、 前記第１制御フロー・パス中で未解決な選択点を識別する段階と、 前記未解決な選択点を、前記選択点の解決の可能性のそれぞれに対するエッジ を含むツリー中のノードで表す段階と、 第１の未選択のエッジを無作為に選択して第１選択を決定することにより、前 記未解決な選択点を解決する段階と をさらに含む請求項２５に記載の方法。 ２８．前記未解決な選択点を解決する前記段階が、 前記第１選択の履歴を維持する段階と、 第２の未選択の前記エッジを無作為に選択して第２選択を決定する段階と をさらに含む請求項２７に記載の方法。 ２９．第１制御フロー・パスを前記コンピュータ・プログラムを介してトラバー スする前記段階が、 前記第１構造メモリ・モデルを更新して、前記未解決な選択点を解決する前記 段階を反映する段階と、 をさらに含む請求項２７に記載の方法。 ３０．前記コンピュータ・プログラムの前記表現を分析して関数呼出しを識別す る段階と、 前記関数呼出しに対応する呼び出された関数の外部動作モデルを突き止める段 階と、 前記関数呼出しに対応する呼び出された関数の前記外部動作モデルを検索する 段階とをさらに含む請求項２５に記載の方法であって、前記第１構造メモリ・モ デルを操作して前記ステートメントの前記第１列の実行をシミュレートする前記 段階が、 前記関数呼出しに対応する呼び出された関数の前記外部動作モデルの実行を介 して前記関数呼出しの実行をエミュレートする段階をさらに含む方法。 ３１．前記第１構造メモリ・モデル中の前記無効条件が、メモリの初期化されて いない部分を知らせる請求項２５に記載の方法。 ３２．前記第１構造メモリ・モデル中の前記無効条件が、無効ポインタを知らせ る請求項２５に記載の方法。 ３３．前記第１構造メモリ・モデル中の前記無効条件が、ゼロ因子を知らせる請 求項２５に記載の方法。 ３４．前記第１構造メモリ・モデルを操作する前記段階を記述する情報をログし て、第１ログ・データを生成する段階 をさらに含む請求項２５に記載の方法。 ３５．前記コンピュータ・プログラムを自動モデル化して前記コンピュータ・プ ログラムに対応する外部動作モデルを生成する段階をさらに含む請求項３４に記 載の方法であって、前記自動モデル化段階が、 前記第１ログ・データを走査して、前記第１制御フロー・パスについての第１ のアウトカムを生み出す段階を含む方法。 ３６．前記コンピュータ・プログラムを自動モデル化する前記段階が、 前記第１構造メモリ・モデルを操作する前記段階を記述する情報をログする前 記段階の前に、前記第１構造メモリ・モデルへの１つまたは複数のリンタを含む 記号表を順序づけする段階をさらに含む請求項３５に記載の方法。 ３７．前記コンピュータ・プログラムを自動モデル化する前記段階が、 前記第１ログ・データを操作して、前記コンピュータ・プログラムのエクスタ ーンを識別する段階 をさらに含む請求項３５に記載の方法。 ３８．ステートメントの第２列を含む第２制御フロー・パスを、コンピュータ・ プログラムを介してトラバースする段階と、 第２構造メモリ・モデルを操作する前記段階を記述する情報をログして、第２ ログ・データを生成する段階と を含み、前記トラバース段階が、 第２制御フロー・パスにわたってコンピュータ・プログラムについて第２構 造メモリ・モデルを維持する段階、および 第２構造メモリ・モデルを操作してステートメントの第２列の実行をシミュ レートする段階を含む請求項３７に記載の方法であって、前記コンピュータ・プ ログラムを自動モデル化して前記コンピュータ・プログラムに対応する外部動作 モデルを生成する段階が、 前記第２ログ・データを走査して、前記第２制御フロー・パスについての第 ２のアウトカムを生み出す段階と、 前記第１のアウトカムおよび前記第２のアウトカムの間の重複を解消して、 １つまたは複数の残りのアウトカムを生成する段階と、 前記残りのアウトカムおよび前記エクスターンを、前記コンピュータ・プロ グラムに対応する前記外部動作モデルにパッケージする段階と を含む方法。 ３９．前記第１コンピュータ・プログラムが第２コンピュータ・プログラムの一 部分であり、前記コンピュータ・プログラムを自動モデル化する前記段階で生成 された前記外部動作モデルが、前記第２コンピュータ・プログラムの分析におい て前記第１コンピュータ・プログラムをエミュレートするために使用される請求 項２５に記載の方法。 ４０．１つまたは複数のステートメントを含むコンピュータ・プログラム中のエ ラーを検出するためのエラー検出プロセッサであって、 シミュレーション時の前記コンピュータ・プログラムの動作を表す構造メモリ ・モデルと、 前記ステートメントの列から構成される制御フロー・パスを、前記コンピュー タ・プログラムを介してトラバースする分析エンジンと、 前記制御フロー・パス中の前記ステートメントの結果をシミュレートするステ ートメント・ユニットと、 前記シミュレーション後に前記構造メモリ・モデル内で検出された無効条件を 報告するエラー生成ユニットと を含むエラー検出プロセッサ。 ４１．外部動作モデルを生成して、前記コンピュータ・プログラムの可視の動作 を表す自動モデラ をさらに含む請求項４０に記載のエラー検出プロセッサ。