JPH10509258A - コンピュータプロセスのリソースのモデル化方法及び装置 - Google Patents

Abstract

(57)【要約】 コンピュータプログラム中のプログラミングエラーを検出するためのエラー検出機構。コンピュータプログラムのコンポーネント（例えばコンピュータプログラムの手続きまたは関数）を解析して、そのコンポーネントがコンピュータプログラムによって使用されるリソースに与える影響を決定する。コンポーネントの解析は、そのコンポーネントのコンピュータ命令、即ちステートメントをトラバースし、そのコンポーネントの影響を受けるコンポーネントによって使用されるリソースの状態を追跡することによりなされる。各リソースは複数の状態とそれらの状態間遷移とによって表される所定の挙動を有する。コンポーネントのステートメントのエミュレートされた実行の結果生じるリソースの所定の挙動に対する違反を検知し、プログラミングエラーとして通知する。２以上のコンポーネントによって使用されるリソースは、コンポーネントのエクスターナル（external）をモデル化することによってモデル化される。コンポーネントの実行がそのコンポーネントのリソース及びエクスターナルに与える影響は、そのコンポーネントの１または複数の可能な制御流れ経路をトラバースし、各制御流れ経路の各ステートメントによる各エクスターナル及びリソースの使用を追跡することによって決定される。コンポーネントの実行がそのコンポーネントのリソース及びエタスターナルに与える影響が決定されると、そのコンポーネントのモデルが生成され、そのモデル化されたコンポーネントによって呼び出される他のコンポーネントのリソース及びエクスターナルをモデル化するのに使用される。

Description

【発明の詳細な説明】 コンピュータプロセスのリソースのモデル化方法及び装置付録Ａについて 本開示の一部である付録Ａは、以下により詳しく説明する本発明の一実施例に おけるコンピュータプログラム及び関連するデータのリストである。 本特許文献の開示の一部には著作権保護に従う題材が含まれている。本著作権 所有者は、特許商標庁の特許ファイルまたは記録に掲載される場合は、本特許文 献または特許開示が誰によって複製されてもそれに異議を唱えるものではないが 、それ以外の場合は全ての著作権を保留するものである。発明の背景 発明の技術分野 本発明はコンピュータプログラムの解析に関する。特に、コンピュータプログ ラムによって定められたリソースの使用の解析を通して、コンピュータプログラ ム内のプログラミングエラーを検出することに関する。関連する技術分野の説明 既存のプログラミングエラー検出方法には、特定のプログラムが従うべきコン ピュータ命令プロトコル（computer instructionprotocol）における違反を検出 するものがある。そのようなプログラムエラー検出方法は“スタティックチェッ ク法（static checking）”と呼ばれているが、それはコンピュータプログラム のコンピュータ命令（または“ステートメント”）の文法が、それらのステート メントの実行から生じる挙動の文脈（context）の外で解析されるからである。 “ステートメント”という用語は、本明細書中では、Herbert Schildtによる“注釈版ANSI Ｃスタンダード (Osborne McGraw-Hill 1990)”（以下、Ｃスタンダ ードと呼 ぶ）として再版された“American National Standard for ProgrammingLanguage s--C (American National Standards Institute/International Organization fo r Standardization ANSI/ISO 9899-1990)”のセクション６．６において定義さ れている意味で使用される。簡単に説明すると、Ｃ言語の文脈において、ステー トメントとは宣言ではないコンピュータ命令である。言い換えると、ステートメ ントとは、コンピュータに指示を与えて１または複数の処理過程を実行させる任 意の式または命令である。Ｃ言語の文脈におけるスタティックチェック法には、 （ｉ）コンピュータプログラム中に同じ名前が付けられた２つの変数がないこと を確認すること、（ｉｉ）各“ｂｒｅａｋ”ステートメントが先行する“ｗｈｉ ｌｅ”、“ｆｏｒ”または“ｓｗｉｔｃｈ”ステートメントに対応していること を確認すること、及び（ｉｉｉ）演算子が適切なオペランドに対して施されてい ることをベリフィケーションすることなどが含まれる。スタティックチェック法 については、例えば、Alfred V．Aho らによる“Compilers(Addison Wesley 198 8)”に記載されている。 一般に“データ流れ解析”技法と呼ばれている、既存のスタティックチェック 法のあるものは、プログラミングエラーを検出するため、プログラム中のデータ の流れを解析する。このような解析は、例えば、ある変数に値が代入される前に その変数を使用するといった不適切なデータオブジェクトの使用を検出するため 、ステートメント及びループステートメントを順に並べるなどして、制御流れ情 報を活用する。あるコンピュータプログラムにおける制御流れとは、そのコンピ ュータプログラムによって定義されるコンピュータプロセスにおいてそのコンピ ュータプログラムのコンピュータ命令が実行されていく特定の順序のことである 。コンピュータプログラム及びプロセス、及びそれらの関係については、後によ り詳しく説明する。データ流れ技法については、Beizerによる “Software Testing Techniques,（1990）pp.145-172”に記載されている。 既存のスタティックチェック法には、まとまってコンピュータプログラムを形 成する関数のようなコンピュータプログラムの幾つかの個々のコンポーネントを 通じたリソースの使用の追跡が不可能であるという欠点がある。例えば、ある変 数が第１の関数において初期化され、第２のそれに続いて実行される関数におけ る計算において使用されるということがあり得る。第２の関数のコンピュータ命 令を解析するだけでは、その変数は初期化される前に使用されるようにみえ、こ れは誤ってエラーとして通知される可能性がある。更に、既存のスタティックチ ェック法は本質的に静的（static）であり、特定のデータオブジェクトに関連付 けられる特定のデータ値を考慮することはない。静的な解析は、プログラムの実 行の動的な効果を考慮することなく決定することができることに限定される。Be izerは、静的な解析が不適当である幾つかの領域について述べている。それらに は、配列、特に動的に計算される指標及び動的に割り当てられる配列；レコード 及びポインタ；ファイル；及び交互状態テーブル（alternate state tables）が 含まれる。これらは同じプログラムにおいて異なる型の異なる意味（semantics ）を表す。 スタティックチェッカ（static checker）は、動的に割り当てられるメモリ（ dynamically allocated memory）に対応して計算されるアドレスまたは配列をな すように計算される指標を含むエラーを検出しない。計算されるアドレス及び指 標は、それぞれコンピュータプロセスの実行中に計算されるアドレス及び指標で ある。スタティックチェッカがそのようなエラーをコンピュータプログラム中で 検出しないのは、そのようなエラーの調査には、通常、計算されるアドレス及び 指標の正確な値を決定することが含まれ、それには実行時のコンピュータプログ ラムの挙 動を考慮すること即ちコンピュータプロセスとして考慮することが含まれるから である。 またスタティックチェッカは、正常に割り当てられるか疑わしいリソースの使 用や、変数または他のデータオブジェクトの値によって状態を決定されるリソー スの使用を含むエラーを検出しない。Ｃ言語では、リソース（例えば、動的に割 り当てられるメモリまたはファイル）が正常に割り当てられるかどうか疑わしい 。言い換えると、リソースを割り当てる関数は、リソースの割り当てに失敗して も正常に終了する。割り当てが成功したかどうかは、関数の戻り値項目（割り当 てられたリソースを指すポインタ）を無効値（例えばＮＵＬＬ）と比較すること によって判定されるのだが、スタティックチェッカは呼び出される関数の挙動を 考慮することはせず、被呼び出し関数に対する呼び出しの文法が、特定のコンピ ュータ言語において定められた文法に従っているかどうかのみをベリフィケーシ ョンする。従って、スタティックチェッカは正常に割り当てられるかどうか疑わ しいリソースの使用を含むエラーを検出しない。 上述したように、スタティックチェッカは呼び出される関数の挙動を考慮しな い。従って、複数の関数にまたがったリソースの使用をベリフィケーションする ことは不可能である。例えば、第１の関数がリソースを割り当てを行い（alloca te）、第２の関数がそのリソースを使用し、第３の関数がそのリソースを開放（ deallocate）する場合、第１、第２、及び第３の関数のいずれかを単独で、また は３つの関数の全ての呼び出しをする一つの関数を静的に調べることによっては 、リソースの適切な使用をベリフィケーションすることはできない。 実行時のコンピュータプログラムの挙動に関する情報を十分に使用しないエラ ー検出技法が用いられる場合、そのような技法によって検出さ れるエラーは過小に検出されるかあるいは過大に検出されるかのいずれかとなる 。例えば、ある関数が、割り当てられるリソース（例えば、ファイル）を指定す るポインタをパラメータとして受け取り、そのパラメータを無効ポインタと比較 することなく使用するような場合、その関数はエラーを含む可能性を有する。そ の関数がエラーを含むかどうかは、その関数の文脈内ではわからない様々な状況 に依存する。例えば、そのポインタが関数が呼び出される前に有効なポインタで あるとベリフィケーションされる場合、その関数はエラーを含まない。そのポイ ンタの使用をエラーとして通知することは、誤ったエラー通知でその関数の解析 を混乱させ、エラーを過大にすることとなる。大きなプログラムの解析において 誤ってエラーを通知することは、よくてもプログラム開発者をわずらわせ、悪け ればコンピュータプログラムの解析を役に立たないものとしてしまう。関数を呼 び出す前にポインタが有効であるかチェックされない場合に、エラーの通知をし ないと、実行時にコンピュータプログラムを突然アボートさせ、データ構造の破 壊や有効なデータの損失といった結果を生じさせ得るエラーの検出がなされない こととなる。 コンピュータプログラムの動的な挙動を考慮しないスタティックチェック法の 欠点の１つは、明白な、しかし“虚偽の”エラーの通知をすることである。即ち 、制御が流れ得ないコンピュータ命令から生じるエラーを通知することである。 制御流れ経路（control flowpath）が特定のデータ構造及びプログラム変数に関 連付けられる特定の値に依存するような関数では、制御流れはこれらのデータ構 造及び変数に関連付けられる値を考慮することなくして決定することはできない 。また、これらのデータ構造及び変数に関連付けられる値は、一般に、実行時の 関数の挙動を考慮することなくして決定することはできない。その結果、実行さ れない命令または特定の状態の下でしか実行されない命令は一般にスタ ティックチェッカでは常に実行されるものと仮定される。 既存のプログラミングエラー検出技法の別のタイプに、プログラムベリフィケ ーション（program verification）と呼ばれるものがある。プログラムベリフィ ケーションでは、コンピュータプログラムは形式的な数学的対象として扱われる 。コンピュータプログラム中のエラーは理論数学を用いてコンピュータプログラ ムの所定の特性を立証すること、または立証するのに失敗することによって検出 される。一般に立証が試みられる特性の１つは、所定の入力が与えられたとき、 コンピュータプログラムによって定義されたコンピュータプロセスが所定の出力 を生成するということである。その立証が失敗に終わる場合、コンピュータプロ グラムはプログラミングエラーを含む。このようなプログラムベリフィケーショ ン技法は、例えば、Eric C．R．Hehnerらによる“A PracticalTheory of Progra mming ，(Verlag 1993)”及び Ole-Johan Dahlによる“Verifiable Programming ，(Prentice Hall 1992)”に記載されている。 プログラムベリフィケーション技法は少なくとも２つの意味で制約を受ける。 即ち、（ｉ）形式的論理を用いて表現し自動的に立証することができるコンピュ ータプログラムの特性のみがベリフィケーション可能である、（ｉｉ）コンピュ ータプログラムの開発者は、コンピュータプログラムの特性を形式的に明確に表 さなければならない。コンピュータプログラムの特性を形式的に表すことは、ど んな場合にも極めて困難なことであり、大きなプログラムでは殆ど不可能である 。そのため、プログラムベリフィケーション技法を用いた商業的に成功した商品 は極めて希である。 プログラミングエラー検出技法の別のタイプでは、コンピュータプログラムが 実行され、従ってコンピュータプロセスが形成され、コンピュータプロセスの挙 動が監視される。コンピュータプログラムの解析がプ ログラムの実行中になされるため、そのようなプログラムエラー検出技法は“ラ ンタイムチェック法（runtime checking）”と呼ばれる。ランタイムチェック技 法の中には、コンピュータ命令をコンピュータプログラム中に自動的に挿入して 、コンピュータプログラムの実行時に、挿入されたコンピュータ命令が実行され ることによって、コンピュータプログラムの変数及びリソースの状態が示される ようにするものがある。そのようなエラー検出技法は、Hastingsに付与された米 国特許第５，１９３，１８０号明細書に記載されている。 ランタイムチェックでは、通常、メモリリーク（memory leaks）や禁止領域に 入った配列の指標のようなエラーを検出することができる。ランタイムチェック の例として、カリフォルニア州サニーベイル（Sunnyvale，California）“Pure Software Inc.”から入手可能な“Purify”や、カリフォルニア州パサデナ（Pas adena，California）の“Parasoft Corporation”から入手可能な“Insight”な どがある。“Purify”は、コンピュータがコンパイルされてオブジェクトコード 形式になった後にコンピュータプログラムをモニタリングするためのコンピュー タ命令を挿入する。“Insight”は、コンピュータプログラムがコンパイルされ る前に、即ちコンピュータプログラムがまだソースコード形式のときに、コンピ ュータプログラムをモニタリングするためのコンピュータ命令を挿入する。 ランタイムチェックは、一般に、実際の特定の入力を使ってコンピュータプロ グラムのコンピュータ命令を実際に実行することによって判定可能なものに限定 される。ランタイムチェッタ法はコンピュータプログラムの制御の流れの全経路 を考慮することはせず、実行時にコンピュータプログラムに与えられる特定の入 力に対応した経路しか考慮しない。一般に、コンピュータプログラムのコンピュ ータ命令の実行によって形 成されるコンピュータプロセスを、全ての可能な制御流れ経路を通るようにする ことは実際的ではない。そのようにするには、プログラマーが、コンピュータプ ログラムのコンピュータ命令の実行時に発生し得る全ての事象を予期し、そのよ うな事象発生の全ての組み合わせを生じさせるまたはエミュレートすることが必 要であるからである。 更に、ランタイムチェックは、コンピュータプログラムが完成しているときし か使用することができない。ランタイムチェッタでは、ある１つの関数が完成し たプログラムに組み込まれる前に、その関数を解析することは不可能である。な ぜなら、解析するにはその関数を実行しなければならないからである。従って、 ランタイムチェックを用いて関数を解析するには、（ｉ）コンピュータプログラ ムの全ての関数が、それらの関数のどれかを解析するよりも前に、開発され、組 み合わされてコンピュータプログラムを形成していること、または（ｉｉ）関数 をテストするために、その関数を組み込んだ特別なテストプログラムが開発され ていることが必要である。従って、完成したコンピュータプログラムへの組み込 み前に個々の関数の設計、制作及びテストを行う、複雑なコンピュータプログラ ムを開発する好適な方法であり広く知られているトップダウン式のプログラミン グは、ランタイム解析にはなじまない。 必要とされているのは、コンピュータプログラムの動的な挙動を考慮し、自動 的にコンピュータプログラムの概ね全ての制御流れ経路を考慮し、コンピュータ プログラムのプログラマーがコンピュータプログラムを別の形式、例えば数学的 形式、で表すことを必要としないプログラミングエラー検出技術である。更に必 要とされているのは、プログラムの個々のコンポーネントを、実行時のそのコン ポーネントの挙動を考慮して解析するプログラミングエラー検出技術である。更 に必要とされているのは、解析中のコンピュータプログラムコンポーネントによ って実行 を喚起されるコンポーネントの挙動を考慮するプログラミングエラー検出技術で ある。発明の要約 本発明によると、コンピュータプログラムによって使用されるリソースの挙動 をモデル化し、それらのリソースにおいて発生する可能性のある状態違反を検出 することによって、コンピュータプログラムの解析がなされコンピュータプログ ラム中のプログラミングエラーが検出される。リソースは、リソース状態とリソ ースの挙動を表すリソース状態遷移とに基づいてモデル化される。コンピュータ プログラムのコンピュータ命令は動的に検査される。即ち、コンピュータ命令の 動的挙動が決定され、コンピュータ命令の動的挙動に従ってリソースの状態が変 化させられる。 コンピュータプログラムの各コンポーネントは個々に解析される。使用が複数 のコンポーネントに渡るリソース、例えば第１コンポーネントによって割り当て られ、第２コンポーネントによって使用され、第３コンポーネントによって開放 されるリソースの使用は、各コンポーネントのエクスターナル（external）をモ デル化することによって解析される。コンピュータプログラムの２つのコンポー ネントは、各コンポーネントのエクスターナルを通じて互いにコミュニケートす る。例えば、第１コンポーネントによって割り当てられるリソースに関する情報 が、そのリソースを使用する第２コンポーネントに、第１及び第２コンポーネン トのエクスターナルを通して伝達される。各コンポーネントの挙動をそのコンポ ーネントのエクスターナルに関して解析することによって、使用が複数のコンポ ーネントに渡るリソースの適切なモデル化がなされる。 各コンポーネントが解析されると、コンポーネントの実行がそのコンポーネン トの各エクスターナルに与える影響が決定される。コンポーネントの解析から、 コンポーネントのモデルが生成される。コンポーネン トのモデルは、そのコンポーネントの実行がそのコンポーネントの各エクスター ナルに対して与える影響を、エクスターナルのそれぞれの状態の変化とそのコン ポーネントのいずれかのエクスターナルに関連付けられる新たなリソースの導入 とに関して記述するものである。モデル化されるコンポーネントの実行が与える 影響の数及び影響されるエクスターナルは任意であり、これらの影響はエクスタ ーナルの複合状態（composite state）に表される。生成されたコンポーネント のモデルは、モデル化されたコンポーネントの実行を喚起する他のコンポーネン トの解析に用いることができる。図面の簡単な説明 第１図はコンピュータのブロック図である。 第２図は、コンピュータプロセスコンポーネント、そのコンポーネントのリソ ース、及び他のコンポーネントのブロック図である。 第３Ａ図及び第３Ｂ図は、本発明の一実施例に基づくリソースのモデル化を表 した状態図である。 第４Ａ図、第４Ｂ図、第５Ａ図及び第５Ｂ図は、本発明の一実施例に基づくエ クスターナルのモデル化を表した状態図である。 第６図及び第７図は、本発明に基づくリソースチェッカ（resource checker） のブロック図である。 第８図は、本発明に基づく動的検査エンジンのブロック図である。 第９図は、本発明に基づくコンピュータプログラムの解析の論理流れ図である 。 第１０図は、第９図の論理流れ図におけるモデルの初期化の論理流れ図である 。 第１１図は、本発明の実施例に基づく関数モデル構造体（function model str ucture）のブロック図である。 第１２図は、本発明の実施例に基づくエクスターナルモデル構造体（external model structure）のブロック図である。 第１３図は、関数モデル構造体及びその関数モデル構造体に関連付けられた２ つのエクスターナルモデル構造体のブロック図である。 第１４図は、本発明の実施例に基づく関数構造体（function structure）のブ ロック図である。 第１５図は、本発明の実施例に基づくエクスターナルリスト構造体（external list structure）のブロック図である。 第１６図は、本発明の実施例に基づく宣言構造体（declaration structure） のブロック図である。 第１７図は、本発明の実施例に基づく型構造体（type structure）のブロック 図である。 第１８図は、本発明の実施例に基づくフィールド構造体（field structure） のブロック図である。 第１９図は、２フィールドのデータオブジェクトのブロック図である。 第２０図は、型構造体及び第１９図のデータオブジェクトを表す２つのフィー ルド構造体のブロック図である。 第２１図は、本発明の実施例に基づくステートメント構造体（statement stru cture）のブロック図である。 第２２図は、本発明の実施例に基づく式構造体（expression structure）のブ ロック図である。 第２３図は、本発明の実施例に基づく式構造体、関連付けられた宣言構造体及 び関連付けられた項目構造体（item structure）のブロック図である。 第２４図は、本発明の実施例に基づく個々のコンピュータプログラムコンポー ネントの解析の論理流れ図である。 第２５図は、第２４図の論理流れ図中の一過程の論理流れ図である。 第２６図は、第２４図の論理流れ図に基づくコンピュータプログラムコンポー ネントの繰返し評価の一回分の論理流れ図である。 第２７図は、本発明の実施例に基づく項目構造体（item structure）のブロッ ク図である。 第２８図は、本発明の実施例に基づくステートメントの解析の論理流れ図であ る。 第２９図は、本発明の実施例に基づく式の評価の論理流れ図である。 第３０図は、本発明の実施例に基づくエクスターナル構造体のブロック図であ る。 第３１図は、本発明の実施例に基づくリソース構造体（resource structure） のブロック図である。 第３２図は、本発明の実施例に基づく項目への演算の適用の論理流れ図である 。 第３３Ａ図、第３３Ｂ図、及び第３３Ｃ図は、本発明の実施例に基づく演算子 の処理の論理流れ図である。 第３４図は、本発明の実施例に基づく宣言の処理の論理流れ図である。 第３５図は、本発明の実施例に基づく“ｉｆ”ステートメントの処理の論理流 れ図である。 第３６図は、本発明に基づく論理演算子の処理の論理流れ図である。 第３７図は、第３６図の論理流れ図の一過程の処理の論理流れ図である。 第３８図は、第３６図の論理流れ図の別の過程の処理の論理流れ図である。 第３９図は、本発明の実施例に基づく“ｒｅｔｕｒｎ”ステートメントの処理 の論理流れ図である。 第４０図は、本発明の実施例に基づく“ｂｌｏｃｋ”ステートメントの処理の 論理流れ図である。 第４１図は、本発明の一実施例に基づくリソースリークの検出の論理流れ図で ある。 第４２図は、本発明の実施例に基づくエクスターナルの複合状態の合成の論理 流れ図である。 第４３図は、本発明の実施例に基づく関数の解析からの関数モデルの生成の論 理流れ図である。 第４４図は、第４３図の論理流れ図の一過程の処理の論理流れ図である。 第４５図は、本発明の実施例に基づくある項目の値の別の項目への代入の論理 流れ図である。 第４６図は、本発明の一実施例に基づく被呼び出しルーチンのエミュレーショ ンの論理流れ図である。詳細な説明 本発明によると、コンピュータプログラム中のエラーは、そのコンピュータプ ログラムによって使用されるリソースをモデル化し、それらのリソースに於いて 発生し得る状態違反（state violation）を検出することによって検出される。 まず、リソースの挙動をリソースの状態と状態遷移とに関して模擬することによ ってリソースをモデル化する。コンピュータプログラムの各コンピュータ命令を 解析し、コンピュータ命令の実行がリソースに及ぼす影響に基づいてリソースの 状態を変化させる。状態違反、即ちリソースの状態に於ける無効な状態及び無効 な状態遷移を検出し、プログラムエラーとして通知する。このようにして、本発 明によるエラー検出はコンピュータプログラムによって定義されたコンピュータ プロセスの挙動を考慮し、それによって従来技術のスタティック チェック法の制約の多くを克服するものである。 各リソースは所定の挙動を有し、それは有効な状態とそれらの状態間の有効な 遷移とに関して記述することができる。コンピュータプログラムに於けるエラー 発生の源は、しばしばコンピュータプログラムの開発者がリソースの所定の挙動 を把握していないことにある。コンピュータプログラム中のコンピュータ命令に よって、リソースの所定の挙動に違反したリソースの使用がコンピュータに指示 されると状態違反が発生する。状態違反の例として、例えば、ファイルの所定の 挙動によれば読み出しをするにはファイルが開かれていなければならない場合に おいて、ファイルを閉じた後のファイルからのレコードの読み出しがある。 コンピュータ１００（第１図）には、中央演算装置（ＣＰＵ）１０２、メモリ １０４、及び入力／出力回路（Ｉ／Ｏ回路）１０６が含まれており、これらは全 てバス１０８を介して互いに接続されている。メモリ１０４は、磁気ディスクの ような二次記憶装置、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ （ＲＯＭ）を含む任意のタイプのメモリを含み得る。ＣＰＵ１０２は、メモリ１ ０４からコンピュータプロセス１１０を読み出して実行する。コンピュータプロ セス１１０は、ライブラリ関数１１２、動的に割り当てられるメモリ１１４、及 び第２コンピュータプロセス１１６に対するアクセスを有する。Ｉ／Ｏ回路１０ ６は、ドライバ１０６Ａ、１０６Ｂ、１０６Ｃ、１０６Ｄ、及び１０６Ｅを含ん でおり、これらのドライバはそれぞれビデオモニタ１１８、二次記憶装置１２０ 、ネットワーク１２６、ポインティングデバイス（マウス１２２など）、キーボ ード１２４を駆動・制御する。 本明細書中では、リソースはコンピュータプロセスによって使用されるコンピ ュータシステムの一部であり、一般に、使用前に割り当てられ、使用後に開放、 即ちフリーにされなければならない。リソースの例とし て、グローバルメモリ、ファイル、ウインドウ、メニュー、及びダイアログ（di alog）がある。コンピュータプロセス１１０のリソースには、例えば、動的に割 り当てられるメモリ１１４、コンピュータプロセス１１６、磁気ディスク１２０ が含まれる。 また本明細書中において、コンピュータプロセスとはコンピュータによって実 行される一連の過程（step）である。コンピュータプログラムはコンピュータに よって実行されうる一連の命令である。コンピュータプログラムの命令によって 過程が定義され、それらがコンピュータにより実行されると、コンピュータプロ セスが形成される。従って、コンピュータプロセス１１０の挙動をモデル化する ため、コンピュータプロセス１１０を定義するコンピュータプログラムの解析が なされる。関数レベルでの解析 コンピュータプログラムは、通常、既に開発されているコンポーネントと新た に開発されるコードとを組合せたものである。本明細書中において、“コード” はソースコード、即ち人間に理解可能な形式の一連のコンピュータ命令、及び／ またはオブジェクトコード、即ちコンピュータに理解可能な形式の一連のコンピ ュータ命令を表す。コンピュータプログラムのコンポーネントとは、特定の部分 プロセスを実行するように既に開発され、通常、その部分プロセスが忠実に実行 されることが試験済みであるコンピュータ命令及び／またはデータ構造の集まり である。部分プロセスとは、コンピュータプロセス中の１または複数の過程であ り、即ちコンピュータプロセスの一部である。コンピュータプログラムの開発者 は、特定の部分プロセスを実行するためこのようなコンポーネントを使用し、通 常、そのコンポーネントを信頼しており、実行時には定められた通りに機能する ものと思っている。そのようなコンポーネントは、開発者が既に開発したコンポ ーネントまたは商業的に入手可能な コンポーネントの実行の要求、即ち呼び出し（call）を含むことができる。その ようにして、コンピュータプログラムの開発に於ける作業の重複が避けられてい る。 新たなコンピュータプログラムは、通常、開発済みのコンポーネントを組み合 わせ、新たに書かれたコンピュータ命令を用いてこれらのコンポーネントを互い に接続することによって開発される。そのような組合せ及び相互接続の結果、他 のコンポーネントまたはコンピュータプログラムによって使用可能な新たなコン ポーネント、または新たなコンピュータプログラムが生成される。あるコンピュ ータプログラムのコンポーネントは、そのコンピュータプログラムによって定義 されるコンピュータプロセスの部分プロセスを定義する。コンピュータプロセス の各部分プロセスは、そのコンピュータプロセスによって用いられるリソースの 状態を変化させ得る。従って、あるコンピュータプロセスによって用いられるリ ソースの状態及び状態遷移を適切に解析するには、コンピュータプログラムのコ ンポーネントによって定義される部分プロセスの実行がリソースの状態に与える 影響を確かめなければならない。例えば、第１コンポーネントによって定義され る第１部分プロセスに於いて割り当てられ、第２コンポーネントによって定義さ れる第２部分プロセスに於いて使用され、第３コンポーネントによって定義され る第３部分プロセスに於いて開放されるリソースの使用を適切に解析するには、 第１、第２、及び第３部分プロセスのリソースに対する影響を解析することが必 要である。 コンピュータプログラムは、様々なコンピュータ言語の何れで書かれていても 良い。典型的なコンピュータ言語は手続き型である。手続き型言語において、コ ンピュータプログラムのコンピュータ命令は編成されてコンポーネントを形成し 、これらのコンポーネントは、しばしば手続 き、または“関数”と呼ばれる。それらは各々実行されたとき特定の部分プロセ スを実行するように設計される。手続き型言語の例として、Ｃ、Ada、Pascal、F ortran及びBasicがある。手続き型言語にはオブジェクト指向のものがあり、そ のようなものとして例えばＣ++やSmallTalkがある。オブジェクト指向コンピュ ータ言語では、関数及びデータ構造が結合されてオブジェクトが形成され、それ らのオブジェクトが更に編成されて“クラス（class）”として知られるコンポ ーネントが形成される。 コンピュータ言語にはグラフィックベースのものがあり、そのようなコンピュ ータ言語では、命令はコンピュータスクリーン上に表示されるグラフィックイメ ージとして表される。プログラマーはそれらのグラフィックイメージをリンクし てコンピュータプログラムを形成する。例えば、ワシントン州レッドモンド（Re dmond,Washington）のマイクロソフト社(Microsoft Corporation)から入手可能 な“Microsoft Visual Basic”は、そのようなグラフィックベースのコンピュー タ言語である。コンピュータ言語には、マイクロソフト社から入手可能な“Micr osoft Word”ワープロソフト用の“Microsoft Word Basic”というコンピュータ 言語や、マサチューセッツ州ケンブリッジ（Cambridge，Massachusetts）のロー タスディベロップメント社（Lotus Development Corporation）から入手可能な “Lotus 1-2-3”表計算ソフト用の“Lotus 1-2-3”マクロ言語のように、特定の ソフトウエア製品を対象としたものもある。本発明は、任意のコンピュータ言語 、即ちリソースが使用される任意のコンピュータ命令プロトコルに適用可能であ る。ソースコードのコンピュータ命令プロトコルについて上記で述べたが、本明 細書中に開示することは、オブジェクトコード形式のコンピュータ命令にも同じ ように適用可能であることを理解されたい。以下に示す例示的な実施形態では、 解析されるコンピュータ言語はＣスタンダードに説明されている良く知られたＣ 言語である。 Ｃ言語で書かれたコンピュータプログラムは、通常、いくつかの関数に分割さ れる。関数は、実行されると、入力として０または１以上のパラメータを受け取 り、出力として１つの戻り値項目（returned item）を生成することもあるが、 戻り値項目を生成しないこともある。これらのパラメータ及び戻り値項目はデー タ構造であり、その関数によってアクセス可能なデータを含み、例えばメモリ１ ０４のようなメモリに格納される。Ｃ言語で定義された関数の例を、後にコンピ ュータコードの抜粋（１）に示す。 本明細書中で述べる例示的な実施形態では、コンピュータプログラム内の各関 数は個々に解析される。関数は、その関数のコンピュータ命令によって影響され るその関数のリソース、エスクターナル及び項目の使用及び変化をモデル化する ことによって解析される。関数の項目(item)は、その関数によってアクセス可能 なメモリ（例えばメモリ１０４）中の位置を表す。項目は型（type）と値（valu e）とを有する。本発明の一実施例においてサポートされる項目の型には、整数 、浮動小数点、及びポインタ（pointer）データが含まれる。項目の値とは、そ の項目によって表されるメモリ内の位置に格納された特定のデータによって表さ れる値である。エクスターナル及びリソースは、関数の各項目に関連付けられ得 る。項目については後により詳細に説明する。変数（variable）が、識別子（id entifier）と１または複数の項目との間を関連付ける。 関数のエクスターナルは、その関数の文脈の外、即ち、その関数の実行の始ま る前またはその関数の実行が終了した後に存在するコンピュータプログラムの一 部を表す。関数のエクスターナルの例には、関数のパラメータ及び戻り値項目、 グローバル定義変数、及びスタティック変数が含まれる。用語（ｉ）“グローバ ル定義変数”及び（ｉｉ）“スタテ ィック変数”は、本明細書中では、それぞれ（ｉ）リンケージが“外部的（exte rn）”な変数、及び（ｉｉ）リンケージが“内部的（intern）”で格納期間が“ 静的”な変数を表すのに使用される。“ローカル定義変数”はリンケージが“内 部的”で格納期間が“自動的（automatic）”な変数である。リンケージ（linka ge）については、Ｃスタンダードのセクション６．１．２．２に説明されており 、格納期間（storage duration）についてはＣスタンダードのセクション６．１ ．２．４に説明されている。簡単に説明すれば、グローバル定義変数は、コンピ ュータプロセスの全部分プロセスに対し定義され、スタティック変数は幾つかの 部分プロセスに対し定義されるが、コンピュータプロセスの全部分プロセスに対 して定義されるとは限らない。 各部分プロセスは幾つかのリソースを使用する。例えば、プロセス１１０（第 １図）の関数２０２（第２図）は、動的に割り当てられるメモリ１１４、及びコ ンピュータプロセス１１６を使用する。また関数２０２（第２図）は、（ｉ）関 数２０２Ａ及び２０２Ｂ及び他の関数によってもアクセス可能なグローバル定義 メモリ２０４と、（ｉｉ）ローカルメモリと、（ｉｉｉ）パラメータ２０８Ａ〜 ２０８Ｃと、（ｉｖ）戻り値項目２１０も使用する。関数２０２は、これらのリ ソースの１または複数をモデル化することによって解析される。 各リソース及びエクスターナルは状態（state）を有する。関数の各コンピュ ータ命令の実行は、コンピュータ命令の実際の実行によって生じるであろうその 関数のリソースまたはエクスターナルの状態の変化をモデル化することによって エミュレートされる。エクスターナルまたはリソースの状態が変化する場合、そ の状態変化はそれぞれ対応するエクスターナル挙動モデルまたはリソース挙動モ デルと比較され、その状態変化がエクスターナルまたはリソースの適切な使用を 反映しているかどう かが判定される。状態変化が不適切である場合は、状態違反が発生し、エラーが 通知される。エラーのユーザへの通知は、（ｉ）エラーメッセージをビデオモニ タ１１８（第１図）または同様の出力装置に表示することによって、（ｉｉ）エ ラーメッセージをメモリ１０４または二次記憶装置１２０のエラーログファイル に記録することによって、または（ｉｉｉ）エラーメッセージの表示とエラーメ ッセージの記録を両方とも行うことによって可能である。挙動モデル 関数モデルは、関数をその関数が割り当てる新たなリソース及びその関数のエ クスターナルにその関数が施す演算に関して、抽象して表したものである。 上述したように、リソースは状態を有する。リソースの有効な状態及び有効な 状態間遷移は、リソース挙動モデルによって表される。リソースの挙動のモデル 化は、そのリソースの実際の挙動よりも大幅に簡略化され得る。例えば、リソー スの状態は、状態図３００（第３Ａ図）によって表されるリソース挙動モデルに 基づいてモデル化される。状態図３００に基づくと、リソースは次の状態の何れ かを取り得る。 状態ＵとＸは似ているが別のものである。未割り当てのリソースに関連付けら れた項目は不定値を有し、無効なリソースに関連付けられた項目は既知の無効値 （invalid value）を有する。リソース挙動モデルは挙動がモデル化されるリソ ースの実際の挙動と同程度に複雑になり得る。しかしながら、状態図３００に表 されたような大幅に簡略されたリソース挙動モデルでも、そのようなリソースの 使用に於いて発生し得る全エラーのほとんどを検出する上で有効である。 リソースは最初は割り当てられていないため、状態Ｕにある。各コンピュータ 命令のエミュレートされた実行（それらを実際に実行するとリソースの状態変化 を引き起こす）によって、リソースに演算（operation）が施される。リソース に演算を施すことによって、リソースの状態は状態図３００に従って変化する。 以下にリソースに施すことのできる演算を示す。 このように、状態図３００に従うと、未割り当てのリソース、即ち状態Ｕにあ るリソースに対し、ある関数内の命令によって適確な割り当てがなされる場合、 即ち演算ａが施される場合、そのリソースは状態Ａ、即ち割り当てられた状態と なる。しかしながら、未割り当てのリソース、即ち状態Ｕにあるリソースが計算 に於いて使用される（従って演算ｃを施される）と、そのリソースは状態Ｅとな る。状態Ｅは、プログラミングエラーの結果、状態違反が起こったことを示す。 状態Ｅはリソースの予め定められた挙動を表すものではなくオプション的なもの であるが、開示する実施例に於いては、状態違反を表す便利な方法として使用さ れる。別の実施例では状態Ｅは省略され、状態違反は上記の例に於いてリソース が状態Ｕにあるとき、演算ｃが定義されないことに注目することによって検出さ れる。 状態図３００（第３Ａ図）は表Ｃのようにまとめられる。 状態図３００中の演算識別子に対応している上付の数字、及び表Ｃに於いて新 たな状態識別子に付されている上付の数字は、特定のエラーを示している。これ らのエラーは、次の表Ｄに示す通りである。 上述の例では、演算ｃを状態Ｕにあるリソースに施すことによって、状態図３ ００に於いて状態Ｕから状態Ｅへと向かう“ｃ²”によって識別される矢印によ って示されているように、リソースは状態Ｅに置かれる。このように、この例に 於けるエラーは表Ｄに示したエラー番号２、即ち未割り当てのリソースの使用で ある。 各関数モデルは、対応する関数の各エクスターナルにどの演算が施されるかを 規定する。例えば、Ｃスタンダードのセクション７．９．５．３に説明されてい るＣ言語用に定義された関数ｆｏｐｅｎ () は、２つのパラメータを定め、その うち第１のパラメータは入力として受け取られ、開かれるべきファイルを特定す る。また、開かれたファイルに対応するファイルポインタである戻り値項目を定 める。ファイルポインタ、即ち、型“ＦＩＬＥ”の項目を指定するポインタは、 Ｃスタンダードのセクション７．９．１に説明されておりよく知られている。フ ァイルポインタは関数ｆｏｐｅｎ () のエクスターナルであり、このパラメータ によって特定されるファイルは、このエクスターナルに関連付けられるリソース である。関数ｆｏｐｅｎ () に対する関数モデルは、初期状態が状態Ｑの新たな リソースが生成されることを定める。このリソースの初期状態は状態Ａではなく 状態Ｑであるが、それは関数ｆｏｐｅｎ () はファイルが正常に開かれることを 保証するものではないからである。 Ｃスタンダードのセクション７．９．５．１に説明されているＣ言語用に定義 された関数ｆｃｌｏｓｅ () は、ファイルポインタであるパラメータを定める。 関数ｆｃｌｏｓｅ () を実行することによって、そのパラメータが指定するファ イル記述子（file descriptor）を有するファイルが閉じられる。関数ｆｃｌｏ ｓｅ () に対する関数モデルは、関連するファイルが閉じられること、従って開 放されることが反映されるように、そのパラメータに演算ｋが施されることを定 める。同様に、ファイルに対する読み出し及び書き込み演算を定義するＣ言語の 関数に対する関数モデルは、ファイルが使用されたことが反映されるように、そ のファイルを表すリソースに演算ｃが施されることを規定する。 あるリソースに対応する項目（例えば関数ｆｏｐｅｎ () の戻り値項目である ファイルポインタなど）が、決定命令（decision instruction）中で述語（pred icate）として使用される場合、演算ｐがそのリソースに施され、リソースの状 態は状態図３００に基づいて変化される。項目が関係式（例えば演算子の＞、＜ 、＜＝、＞＝、及び！＝の何れかを含む演算）またはブール式（例えば演算子＆ ＆、｜｜、及び！の何れかを含む演算）中にオペランドとして現れる場合、また は項目が“ｓｗｉｔｃｈ”ステートメントに於いて制御式（control expression ）として用いられる場合、項目は述語中で用いられることとなる。“ｓｗｉｔｃ ｈ”ステートメントはＣ言語用に定義されており、制御式の値に応じて関数の流 れを制御する。“ｓｗｉｔｃｈ”ステートメントについては、Ｃスタンダードの セクション６．６．４．２に詳細に説明されている。 あるリソースに対応する項目が計算中で用いられる場合、演算ｃがリソースに 施され、それにより状態図３００に基づいてそのリソースの状態が変わる。項目 が計算中で使用されるのは、（ｉ）数学的演算（例えば＋、／、＊、または−） に対するオペランドとして現れる場合、また は（ｉｉ）リソースがポインタのデリファレンス（dereference）または配列へ のアクセスとして現れる場合、または（ｉｉｉ）リソースが配列指標として現れ る場合である。 ポインタ及び配列については良く知られており、Ｃスタンダードにも記載され ているが、念のためにポインタ及び配列について以下に簡単に説明する。Ｃ言語 の文脈に於いて、ポインタはその値が他の項目のメモリ中のアドレスであるよう な項目である。従って、ポインタは他の項目を“指定（point）”する。ポイン タをデリファレンスすることは、ポインタが指定する項目を検索することである 。 開示される本発明の実施例を具現するべく用いられる以下により詳細に説明さ れるデータ構造は、他のデータ構造を指定するポインタを含むものとして説明さ れる。データ構造を一意に特定するためのポインタ以外の機構も知られているが 、これらの機構は本発明の原理を逸脱することなくポインタの代わりとなり得る ものであることを理解されたい。 配列は、同様の構造の１または複数の項目の集合である。配列の項目はエレメ ントと呼ばれ、順番に番号付けされる。配列へのアクセスは、エレメントの番号 、即ちエレメントの指標を参照することによる配列のエレメントへのアクセスで ある。 演算ｘは、ＮＵＬＬであるとされる項目に対応するリソースに施される。ＮＵ ＬＬは一般に無効値であり、ある項目が有効な値を有していないことを示すため にその項目に代入される。例えば、値がＮＵＬＬであるポインタは項目の指定を しない。Ｃ言語の文脈では、ＮＵＬＬは“ｆａｌｓｅ（偽）”を表すブール値で もある。ある項目がＮＵＬＬと比較されてその比較の結果がｔｒｕｅ（真）であ るとされる場合、その項目はＮＵＬＬである、即ちＮＵＬＬの値を有するとされ る。後により詳細に説明するように、関数を解析するには、実行時の関数の特定 の挙動に 関して様々な仮定を設定することが必要である。例えば、関数ｆｏｐｅｎ () は 、正常にファイルを開くか、またはファイルを開くのに失敗するか何れかである 。戻り値項目、即ちファイルポインタがＮＵＬＬと比較されその結果がｔｒｕｅ であるとされる場合、即ち関数ｆｏｐｅｎ () がファイルを開くのに失敗したと される場合、そのファイルを表すリソースに演算ｘが施される。これについては 、後により詳細に説明する。本発明の基本的原理を説明するための例 リソースのモデル化の有用性について以下に例を用いて説明する。以下のソー スコード抜粋（１）はプログラミングエラーを含んでおり、開示される本発明の 実施例ではそのプログラミングエラーを検出する。このソースコード抜粋（１） は公知のＣ言語に適合するものであり、関数ｅｘａｍｐｌｅ １ () を定義して いる。ライン番号はＣ言語の一部ではないが、以下の説明をよりわかりやすくす るために付け加えたものである。 関数ｅｘａｍｐｌｅ １ () を解析するとき、エクスターナルを含む 各項目の状態が追跡される。変数“ｓｔｒ”はローカルに定義された、即ち関数 ｅｘａｍｐｌｅ １ () の文脈内でのみ定義されたものである。変数“ｓｔｒ” はライン１０で定義されているように、型が“ｃｈａｒ”であるデータを指定す るポインタである。しかし最初、変数“ｓｔｒ”は初期化されておらず特定のデ ータを指定しない。従って、変数“ｓｔｒ”はリソースに関連付けられていない 。 Ｃスタンダードのセクション７．１０．３．３に説明されているＣ言語用に定 義された関数ｍａｌｌｏｃ () の実行では、割り当てられるメモリ（例えばメモ リ１０４（第１図））に対するリクエストを受け付け、そのメモリを割り当てる かまたはその割り当てに失敗する。関数ｍａｌｌｏｃ () は、戻り値項目として 、メモリの割り当てに成功した場合は割り当てられたメモリを指定するポインタ を、そうでない場合はＮＵＬＬポインタをリターンする。このように、関数ｍａ ｌｌｏｃ () は初期状態がＱである新たなリソースを生成し、その新たなリソー スを関数ｍａｌｌｏｃ () の戻り値項目に関連付ける。ライン２３で関数ｍａｌ ｌｏｃ () の戻り値項目の値が代入された後において、変数“ｓｔｒ”は、メモ リが割り当てられた場合は新たに割り当てられたメモリを指定し、そうでない場 合はＮＵＬＬポインタである。 ソースコード抜粋（１）のライン２５において、変数“ｓｔｒ”は関数ｆｇｅ ｔｓ () 内でパラメータとして用いられている。この関数ｆｇｅｔｓ () もＣス タンダードのセクション７．９．７．２に説明されているＣ言語用に定義された 関数である。関数ｆｇｅｔｓ () を実行すると、ソースコード抜粋（１）のライ ン２５の文脈において、第１パラメータ、即ち、変数“ｓｔｒ”がデリファレン スされる。従って、変数“ｓｔｒ”に関連付けられたリソースに対して演算ｉが 施される。状態図３００（第３Ａ図）及び表Ｃ、表Ｄに示されているように、状 態Ｑのリソ ースに演算ｉを施すとリソースは状態Ａに置かれ、割り当てられているかどうか 不確実なデータがチェックされることなしに使用されたことを示すエラーメッセ ージが生成される。 ソースコード抜粋（１）のライン２９において、変数“ｓｔｒ”は、変数“ｓ ｔｒ”が指定するメモリをフリーにする即ち開放する関数ｆｒｅｅ () にパラメ ータとして渡されている。従って、関数“ｓｔｒ”に関連付けられたリソースに 対し演算ｋが施される。状態図３００及び表Ｃ、表Ｄに示されているように、演 算ｋを状態Ａにあるリソースに施すと、リソースは状態Ｕに置かれる。割り当て られているリソースを開放することは適正であるため、エラーは通知されない。 以下のテキスト（２）は、ソースコード抜粋（１）の関数ｅｘａｍｐｌｅ １ () を解析する、開示される本発明の実施例によって生成されるエラーメッセー ジを示したものである。 テキスト（２）において、“ｅｘａｍｐｌｅ １．ｃ”は、上記のソースコー ド抜粋（１）を含む、従って関数ｅｘａｍｐｌｅ １ () を定義しているファイ ルを表している。関数ｅｘａｍｐｌｅ １ () は、ソースコード抜粋（１）のラ イン２３において関数ｍａｌｌｏｃ () の呼び出し（即ち実行要求）において、 割り当てを要求されるメモリ量に対してメモリが足りないかもしれないというこ とを考慮していない。関数ｅｘａｍｐｌｅ １ () の実行時に関数ｍａｌｌｏｃ () が要求されたメモリの割り当てに失敗すると、関数ｅｘａｍｐｌｅ １ () の実行を含むコンピュータプロセスが突然アボートし、ユーザにはプロセスの予 期されない終了に対する理由も示されないことになる。しかしながら、例えば上 記のテキスト（２）を用いてそのような事態が考慮されていないことを検出し通 知することによって、関数ｅｘａｍｐｌｅ １ () の開発者に、関数ｅｘａｍｐ ｌｅ １ () 中の欠陥を修正するのに必要な情報が与えられ、そのような事態に 適切に対処することが可能となる。 本発明の有用性は、ソースコード抜粋（１）の関数ｅｘａｍｐｌｅ １ () に おけるファイルポインタ“ｆｐｔｒ”の状態の追跡について検討することによっ て更に明らかとなる。ファイルポインタ“ｆｐｔｒ”は関数ｅｘａｍｐｌｅ １ () のローカル定義変数である。ファイルポインタ“ｆｐｔｒ”は、型“ＦＩＬ Ｅ”のデータを指定するポインタである。最初、ファイルポインタ“ｆｐｔｒ” は初期化されておらず、どのリソースにも関連付けられていない。 ライン１４において、関数ｆｏｐｅｎ () の戻り値項目がファイルポインタ“ ｆｐｔｒ”に代入される。上述したように、関数ｆｏｐｅｎ () は、初期状態Ｑの新たなリソースを生成し、その新たなリソースに関数ｆｏｐｅ ｎ () の戻り値項目を関連付ける。ライン１５の“ｉｆ”ステートメントは、フ ァイルポインタ“ｆｐｔｒ”が指定するファイルが正常に開かれたかどうかをフ ァイルポインタ“ｆｐｔｒ”と“ＮＵＬＬ”とを比べることによって判定する。 ファイルポインタ“ｆｐｔｒ”がＮＵＬＬである場合、ファイルは正常に開かれ ておらず、関数ｅｘａｍｐｌｅ １ () は、ユーザにファイルを正常に開くこと ができなかったことを通知して終了する。逆に、ファイルポインタ“ｆｐｔｒ” がＮＵＬＬでない場合は、ファイルポインタ“ｆｐｔｒ”が指定するファイルは 正常に開かれていることがわかり、関数ｅｘａｍｐｌｅ １ () はライン２２へ と進む。ライン１５においてファイルポインタ“ｆｐｔｒ”の比較をすることに よって、ファイルポインタ“ｆｐｔｒ”に関連付けられたリソースに演算ｐが施 される。従って、ファイルポインタ“ｆｐｔｒ”に関連付けられたリソースの状 態は状態Ｑから状態Ａへと変化する。従って、状態図３００及び表Ｃに示されて いるように、計算（演算ｃの適用）または述語（演算ｐの適用）のどちらでファ イルポインタ“ｆｐｔｒ”を使用しても、エラーメッセージは生成されない。従 って、ファイルポインタ“ｆｐｔｒ”の処理に関してエラーは検出されない。 上述したように、関数ｆｏｐｅｎ () 及びｍａｌｌｏｃ () は、実行時、パラ メータ及び戻り値項目のリソースに対して特定の処理を実行する。関数ｆｏｐｅ ｎ () やｍａｌｌｏｃ () のような関数は、コンピュータプロセス１１０によっ てアクセス可能なライブラリ関数１１２（第１図）内に含まれる。そのような関 数の呼び出しは、関数２０２（第２図）に含まれる。本明細書中において、関数 に対する“呼び出し（ｃａｌｌ）”とは、実行時にＣＰＵ１０２（第１図）のよ うなプロセッサに次のような処理をさせるステートメントである。即ち、（ｉ） 関数に０ または１以上の項目をパラメータとして与え、（ｉｉ）関数を実行し、（ｉｉｉ ）関数の評価により生じる値を表す戻り値項目（戻り値項目が関数によって定め られる場合）を生成する。第１の関数が第２の関数に対する呼び出しを含んでい る場合、第１の関数は“呼び出し関数(calling function)”と呼ばれる。また、 第２の関数は“被呼び出し関数（called function）”と呼ばれる。 関数２０２のステートメントによって呼び出される関数の実行によって影響さ れる関数２０２のリソース（第２図）を適切に解析するため、そのような被呼び 出し関数の挙動を記述する関数モデルがサポートされる。一実施例では、そのよ うな関数モデルは、例えばＣスタンダードにあるこのような関数の挙動を定める 公知のテキスト形式の記述から生成され、コンピュータ１００のメモリ１０４内 に格納される。これらの関数モデルはその後コンピュータプログラムの解析に先 立ってメモリ１０４から検索され取り出される。これについては以下により詳細 に説明する。 以下に、上記のソースコード抜粋（１）の関数ｅｘａｍｐｌｅ １ () によっ て呼び出される関数の関数モデルの例を示す。これらの被呼び出関数は全てＣス タンダードのライブラリの“ｓｔｄｉｏ”（入力／出力）ヘッダファイルからの ものである。このヘッダファイルはＣ言語で使用される広く知られたファイルで あり、Ｃスタンダードのセクション７．９以下に示されている。 開示される本発明の実施例に基づく関数モデルをメモリ１０４（第１図）にお いて表す関数モデル構造体については、後に詳述する。関数モデル（３）は、関 数ｍａｌｌｏｃ () の実行が関数ｍａｌｌｏｃ () のエクスターナルの状態に与 える効果について定めている。関数モデル（３）によると、新たなリソースが生 成され、状態Ｑに初期化され、関数ｍａｌｌｏｃ () の戻り値項目に関連付けら れる。また関数モデル（３）は、関数ｍａｌｌｏｃ () の第１パラメータ、即ち 、パラメータ０（parameter O）に演算Ｃが施されることも規定している。 関数モデル（４）は、関数ｆｒｅｅ () の実行が関数ｆｒｅｅ () のエクスタ ーナルに及ぼす効果について規定しており、演算ｋが引数リスト（argument lis t）の第１パラメータ即ちパラメータ０に施されることを示している。 関数モデル（５）は、関数ｆｇｅｐｓ () を呼び出すことによって、（ｉ）演 算ｉがパラメータ０、即ち第１パラメータに施され、（ｉｉ）演算ｃがパラメー タ１、即ち第２パラメータに施され、（ｉｉｉ）演算ｉがパラメータ２、即ち第 ３パラメータに施されることを示している。リソースリークの検出 リソースをモデル化しリソースと関数のエクスターナルとの関連を追跡するこ とによって、開示するエラー検出機構は、リソースリークを検出する有用な機構 を提供する。リソースは、ある関数がそのリソースを割り当てられた状態にした まま終了するとき、即ち、その関数のどのエクスターナルによってもそのリソー スがアクセスできなくなったとき、その関数によって“リーク”される。リーク されると、そのリソースはリークを発生させた関数の実行が終了した後にはその リソースを指定するポインタが保持されないため、使用することができなくなる 。リソースが再使用可能な場合、例えば、動的に割り当てられるメモリ１１４（ 第１図）のような場合、関数の実行の終了前にリソースをフリーにしないと、他 の関数がそのリソースを再使用することができなくなる。ある部分プロセスが動 的に割り当てられるメモリを繰り返しリークさせると、 遂にはその部分プロセス含むコンピュータプロセスに使用可能な全メモリが消耗 される結果となり得る。 リソースリークの検出の例として、ソースコード抜粋（６）の関数ｅｘａｍｐ ｌｅ ２ () について考えてみる。 変数“ｓｔｒ”は関数ｅｘａｍｐｌｅ ２ () のローカル変数であり、従って 関数ｅｘａｍｐｌｅ ２ () 以外の関数にはアクセス可能でない。変数“ｓｔｒ ”が指定するメモリは、ソースコード抜粋（６）のライン２５の“ｒｅｔｕｒｎ ”命令の前にフリーにされていないため、このメモリは関数ｅｘａｍｐｌｅ ２ () をその一部として含むコンピュータプロセス１１０が終了するまで使用する ことができず、開放または再割り当てをすることもできない。従って、このリソ ースはコンピュータプ ロセス１１０から“リーク”する。 関数のエクスターナルは関数の実行の終了後も存在する項目であるため、エク スターナルを通じて到達可能(reachable)な割り当てられたリソースはリークさ れない。特定のエクスターナルに関連付けられていないリソースも、ある場合に は、エクスターナルを通じて到達可能である。例えば、項目の配列の特定のエレ メントに関連付けられたリソースは、その項目の配列の別のエレメントであるエ クスターナルを通じて到達可能である。これは、Ｃ言語によると、ある配列のエ レメントのメモリ中の位置は、その配列の他のエレメントの位置から計算可能で あるからである。 リークは、関数のトラバース(traversal)の終了時にチェックされる。リーク の検出については後により詳細に説明するので、ここでは簡単に要約する。エク スターナルを通じて到達可能な全てのリソースをマーク（印し付け）する。マー クされず且つ割り当てられているリソースはリークされたものとして通知する。 ライン２５において変数“ｓｔｒ”はリターンされないため、変数“ｓｔｒ”は エクスターナルではない。従って、変数“ｓｔｒ”によって指定されるメモリは 、割り当てられており且つ関数ｅｘａｍｐｌｅ ２ () のトラバースの終了時に マークされていない。よって、変数“ｓｔｒ”によって示されるメモリはリーク される。 関数ｅｘａｍｐｌｅ ２ () の解析によって、次のエラーメッセージが生成さ れる。 従来技術のスタティックチェッカは、リソースリークを検出することができな い。従来技術のランタイムチェッカ（runtime checker）は、関数にリソースリ ークを発生させ得る全ての起こり得るイベントを考慮しないことがしばしばあり 、一般に大きなコンピュータプログラムの文脈の外で単一の関数を解析してその 単一の関数内のリソースリークを検出することはできない。対照的に、開示され る本発明の実施例では、大きなコンピュータプログラムの単一の関数を解析する ことによって、リソースリークが効果的に検出される。以下により詳細に説明す るように、開示するエラー検出機構は、関数がリソースリークを発生させるよう な起こり得るイベントを全て考慮する。従って、本発明は、従来技術に対して大 幅に向上している。エクスターナルの複合状態 以下に詳細に説明するように、関数の解析は、その関数の制御の流れを追い、 その関数の個々のステートメントの実行をエミュレートし、エクスターナル及び リソースの状態を追跡することによってなされる。関数の制御の流れとは、その 関数の特定の実行時に実行されるその関数のコンピュータ命令の特定の順番であ る。制御が第１コンピュータ命令から第２コンピュータ命令へと移るとき、第２ コンピュータ命令は第１コンピュータ命令の実行に続いて実行される。関数の制 御の流れは、しばしば本明細書中では、関数の制御流れ経路と呼ばれる。関数の 制御の流れは、しばしば、コンピュータプロセスに於いてその関数によって定義 される部分プロセスの実行中に発生する特定のイベントに依存する。 関数の解析においては、関数の全ての可能な制御流れ経路を考慮する ことが望ましい。従って、関数の制御流れ経路に影響を与えうる全てのイベント を考慮することが望ましい。従来技術のスタティックチェッカは、しばしば、制 御流れ経路を全く考慮しない。ランタイムチェッカは、関数の制御流れ経路に影 響を与えるイベントを操作することによって、コンピュータプロセスの実行中に そのコンピュータプロセスが各制御流れ経路をたどるようにユーザが強制し得る 範囲に於いて、特定の関数の制御流れ経路を考慮するのみである。一方、開示さ れるエラー検出機構は、ユーザが介入することなく、自動的に関数の各制御流れ 経路の解析を行う。更に、開示するエラー検出機構は、関数の解析をその関数を 含むコンピュータプロセスまたはコンピュータプログラムの文脈の外で行うこと ができる。従って、個々の関数を、より大きな関数またはコンピュータプログラ ムまたはプロセス中に組み込む前にエラーに対してより完全にチェックすること ができる。 例として、ソースコード抜粋（６）の関数ｅｘａｍｐｌｅ ２ () について考 えてみる。関数ｅｘａｍｐｌｅ ２ () の正確な制御流れ経路は、関数ｅｘａｍ ｐｌｅ ２ () をコンピュータプロセス内で実行するまでは未知である。例えば 、ライン１４に於いて呼び出される関数ｍａｌｌｏｃ () がリクエストされた通 りにメモリを割り当てるのに成功した場合、制御は、ライン１６の“ｉｆ”ステ ートメントからライン１９の関数ｆｏｐｅｎ () の呼び出しへと流れる。言い換 えると、ライン１４で呼び出されたとき関数ｍａｌｌｏｃ () がリクエストされ た通りに正常にメモリを割り当てる場合、ライン１９の関数ｆｏｐｅｎ () の呼 び出しは、ライン１６の“ｉｆ”ステートメントの実行の後に続く。逆に、メモ リの割り当てが失敗した場合、制御はライン１６の“ｉｆ”ステートメントから ライン１７の“ｒｅｔｕｒｎ”ステートメントへと流れる。ライン１４に於いて 呼び出されたとき関数ｍａｌｌｏｃ () によ るメモリの割り当てが正常になされるかどうかは、通常、コンピュータプロセス に於いて関数ｅｘａｍｐｌｅ ２ () が実行されるまでわからない。 関数ｅｘａｍｐｌｅ ２ () の解析に於いて、関数ｅｘａｍｐｌｅ２ () の全 ての制御流れ経路が考慮されることが望ましい。様々に仮定を変えて関数を何度 もトラバースすることによって、複数の制御流れ経路が考慮される。例えば、関 数ｅｘａｍｐｌｅ ２ () は、一度はライン１４で呼び出される関数ｍａｌｌｏ ｃ () がリクエストされたメモリを正常に割り当てるという仮定の下で、一度は 関数ｍａｌｌｏｃ () がリクエストされたメモリの割り当てに失敗するという仮 定のもとでトラバースされる。 後に詳細に説明する本発明の一実施例では、一つの関数に対し繰り返しトラバ ースがなされ、各トラバースに於いて、ランダムに仮定が設定される。関数ｅｘ ａｍｐｌｅ ２ () の各トラバースは、関数ｅｘａｍｐｌｅ ２ () のエクスタ ーナルの状態を追跡する。各エクスターナルは、関数ｅｘａｍｐｌｅ ２ () の 複数回のトラバースの結果得られる各エクスターナルの幾つかの状態を反映する 複合状態（composite state）を有する。 エクスターナルは、複合ＲＳ、ＣＰ及びＤＫ状態を有する。これらの複合状態 は、２つの目的に用いられる。即ち、（ｉ）関数の様々な制御流れ経路を考慮し たとき不整合を生じるエクスターナルの使用を検出するため、（ｉｉ）関数の実 行がその関数のエクスターナルに与える影響を記述する関数モデルを構築するた め、に用いられる。構築された関数モデルは、その後、モデル化された関数を呼 び出す他の関数を解析するのに用いることができる。 ある特定の関数の文脈内で、各エクスターナルはＣＰ状態、ＤＫ状態、 及びＲＳ状態を有する。エスクターナルのＣＰ状態は、使用される前にエクスタ ーナルがチェックされるかどうかを判定するのに用いられる。“ＣＰ”という用 語は、主として関心のある演算、即ち、演算ｐ（エクスターナルのチェックを表 す）の前の演算ｃ（エスクターナルの使用を表す）、からきている。エクスター ナルのＤＫ状態は、関数によってエスクターナルの割り当て及び／または開放が なされるかどうかを判定するのに用いられる。“ＤＫ”という用語は、ＤＫ状態 の目的、即ち、リソースがキル（“Ｋ”）される、即ち開放される前に定義（“ Ｄ”）されるかどうかを判定するという目的から使用されている。エスクターナ ルのＲＳ状態は、そのエクスターナルにリソースが関連付けられている場合に、 関連付けられているリソースの状態である。“ＲＳ”という用語は、リソース（ “Ｒ”）状態（“Ｓ”）からきている。 ある関数の各エクスターナルは、その関数の複数回のトラバースの結果生じる 複数のＣＰ、ＤＫ、及びＲＳ状態をそれぞれ反映する複合ＣＰ状態、複合ＤＫ状 態、及び複合ＲＳ状態を有する。繰り返しなされる関数の各トラバースの後にお いて、エクスターナルの新たな複合ＲＳ状態が求められるが、以下により詳細に 述べるように、エクスターナルの新たな複合ＲＳ状態は、そのエクスターナルの 前の複合ＲＳ状態と、その関数の最も新しいトラバースの結果生じるそのエクス ターナルに関連付けられたリソースのＲＳ状態とから求められる。同様に、以下 により詳細に述べるように、新たな複合ＣＰ及びＤＫ状態は、前の複合ＣＰ及び ＤＫ状態と、関数の最も新しいトラバースの結果生じるＣＰ及びＤＫ状態とから それぞれ求められる。 状態図３５０（第３Ｂ図）は、複合ＲＳ状態に対する状態及び状態遷移を表し ている。状態図３５０に於いて矢印は、関数のトラバースの結果生じるＲＳ状態 に基づく、前の複合ＲＳ状態からの複合ＲＳ状態遷移 を表す。状態図３５０は表Ｅのようにまとめられる。 状態図４００（第４Ａ図）は、エスクターナルのＣＰ状態に対する状態及び状 態遷移を表す。状態図４００に於いて矢印は、演算を施した結果生じるＣＰ状態 遷移を表す。エクスターナルは次のＣＰまたは複合ＣＰ状態を有し得る。 エスクターナルに施すことのできる演算は、表Ｂを参照して上記に示した通り である。状態図４００は、以下の表Ｈにまとめられる。 状態図４５０（第４Ｂ図）は、エクスターナルの複合ＣＰ状態に対する状態及 び状態遷移を表している。状態図４５０で使用されている矢印は、関数のトラバ ースの結果生じるＣＰ状態に基づく、前の複合ＣＰ状態からの複合ＣＰ状態の遷 移を表す。状態図４５０は以下の表Ｉにまとめられる。 状態図５００（第５Ａ図）は、エスクターナルのＤＫ状態に対する状態及び状 態遷移を表している。状態図５００に於いて矢印は、演算を施した結果生じるＤ Ｋ状態遷移を表すのに使用されている。エスクターナルは、エスクターナルに関 連付けられるリソースに関数の実行が与える効果を反映する、以下のＤＫまたは 合成ＤＫ状態を有し得る。 エクスターナルに施すことのできる演算は、表Ｂを参照して上述した通りであ る。状態図５００は以下の表Ｋにまとめられる。 状態図５５０（第５Ｂ図）はエクスターナルの複合ＤＫ状態に対する状態及び 状態遷移を表す。状態図５５０に於いて矢印は、関数のトラバースから生じるＤ Ｋ状態に基づく、前の複合ＤＫ状態からの複合ＤＫ状態遷移を表すのに使用され ている。状態図５５０は以下の表Ｌにまとめられる。 上記のソースコード抜粋（６）の関数ｅｘａｍｐｌｅ ２ () は、エクスター ナルの複合状態の有用性を示す例となる。 上述したように、関数ｅｘａｍｐｌｅ ２ () の制御の流れは、エミュレーシ ョンによる関数の実行時のイベントに関連して設定される仮定に依存して複数の 経路の内の何れかを通る。例えば、変数“ｓｔｒ”がＮＵＬＬでない場合は、ラ イン１６の“ｉｆ”ステートメントの後に、ライン１７の“ｒｅｔｕｒｎ”ステ ートメントが続き、そうでない場合はライン１９の式が続く。関数ｅｘａｍｐｌ ｅ ２ () の戻り値項目は、関数ｅｘａｍｐｌｅ ２ () のエクスターナルであ る。関数ｅｘａｍｐｌｅ ２ () の戻り値項目への代入は、関数ｅｘａｍｐｌｅ ２ () の特定のトラバースに於いて設定される特定の仮定にのみ基づいて、ソ ースコード抜粋（６）のライン１７、ライン２５またはライン２９に於いてなさ れる。 ライン１７またはライン２５では、戻り値項目にリソースは関連付けられない 。従って、ソースコード抜粋（６）のライン１７またはライン２５の何れかを通 って制御が流れるような関数ｅｘａｍｐｌｅ ２ () のトラバースの後において 、戻り値項目を表すエスクターナルの複合ＲＳ状態は状態Ｕとなる。続いて、制 御がライン２９を通るように関数ｅ ｘａｍｐｌｅ−２ () をトラバースすると、戻り値項目を表すエクスターナルは 、関数ｅｘａｍｐｌｅ ２ () 内で生成されたリソースに関連づけられ、適確に 割り当てられる。即ち、状態Ａとなる。ソースコード抜粋（６）のライン１６乃 至１７により、関数ｍａｌｌｏｃ () の実行によってメモリが正常に割り当てら れないというイベントに対して取られるべき動作が適切に記述されているため、 リソースの適確な割り当てがなされるのである。 状態図３５０（第３Ｂ図）に示されているように、前の複合ＲＳ状態が状態Ｕ で次のＲＳ状態が状態Ａであるようなエクスターナルは、状態Ｑの新たな複合Ｒ Ｓ状態を有する。これは、関数ｅｘａｍｐｌｅ ２の実行によって、その戻り値 項目が指定するメモリの割り当てがなされ得るが、必ずしも割り当てがなされる というわけではないということを反映している。従って、関数ｅｘａｍｐｌｅ ２の挙動を記述する関数モデルを形成するとき、関数ｅｘａｍｐｌｅ ２の戻り 値項目は、初期状態が状態Ｑである新たに生成されるリソースに関連付けられる ものとして記述される。 また、複合状態を用いて、関数によるエクスターナルのつじつまのあわない使 用を検出することができる。例えば、ある関数が、エクスターナルが割り当てら れた状態、即ち状態ＡのＲＳ状態で終了し、その関数のその後のトラバースに於 いて、その関数が同じエクスターナルを開放した状態で、即ち状態ＫのＲＳ状態 で終了する場合、そのエスクターナルの複合ＲＳ状態は状態Ｅとなる。これはエ ラーとみなすことができる。なぜなら、一般に、呼び出し関数がある場合の実行 においてはあるエクスターナルに関連付けられたリソースの割り当てをすること を求め、別の場合の実行においては同じエクスターナルに関連付けられたリソー スを開放することを求めるということは考えられないからである。コンピュータプログラムの解析 コンピュータプログラム６１０（第６図）の解析は、本発明に基づいて、本明 細書中に説明するように、コンピュータプログラム６１０によって定められたリ ソースの使用を解析するリソースチェッカ（resourcechecker）６０２によって なされる。開示する実施例では、リソースチェッカ６０２は、バス１０８を介し てＣＰＵ１０２に接続されたメモリ１０４から読み出されてＣＰＵ１０２におい て実行されるコンピュータプロセスである。 コンピュータプログラム６１０の本発明に基づく解析を、論理流れ図９００（ 第９図）に示す。プロセスはステップ９０２において開始される。例えばキーボ ード１２４（第１図）やマウス１２２を用いてユーザが入力するコマンドによっ て、コンピュータプログラム６１０が解析される環境特性が特定され、コンピュ ータプログラム６１０（第６図）の解析が開始される。ユーザによって変更可能 な環境特性には、（ｉ）検出するべきエラーのタイプ、（ｉｉ）通知するべきエ ラーの最大数、（ｉｉｉ）解析するべき関数の最大数、（ｉｖ）各関数のトラバ ースの繰り返しの最大回数、及び（ｖ）関数の全ての可能な制御流れ経路をトラ バースするための特定の方法などがある。 プロセスは、ステップ９０２（第９図）からステップ９０４に進み、そこでリ ソースチェッカ６０２（第６図）は、コンピュータプログラムによって使用され る様々な関数の実行がリソースに与える影響を記述する関数モデルを初期化する 。リソースチェッカ６０２はモデルパーザ７０２（第７図）を含んでおり、モデ ルパーザ７０２は、モデル記述ファイル６０４（第６図）からモデルを読み出し 、読み出したモデルから後述する関数モデル構造体を構築する。リソースチェッ カ６０２において関数モデル構造体を生成することによって、関数モデルが初期 化される。 ステップ９０４（第９図）については、後に論理流れ図９０４（第１０図）を参 照してより詳細に説明する。 プロセスはステップ９０４（第９図）からステップ９０６に進み、そこでリソ ースチェッカ６０２の一部であるプログラムパーザ７０４（第７図）は、コンピ ュータプログラム６１０（第６図）を読み出してきて、従来の技術を用いて、コ ンピュータプログラム６１０が従う言語に基づきパージング（parsing）を行う 。プログラムパーザ７０４（第７図）はコンピュータプログラム６１０（第６図 ）をパージングして、より小さなプログラムコンポーネント、例えば関数、に分 解する。ステップ９０６（第９図）では、１つの関数がコンピュータプログラム ６１０（第６図）からパージングにより抽出され、抽出されたその関数を表す関 数構造体が、後に詳述する動的検査エンジン（dynamic inspection engine）７ ０６に送られる。別の実施例では、後述するプリプロセッサがコンピュータプロ グラム６１０をパージングし、パージングにより抽出されたコンピュータプログ ラム６１０内の複数の関数を表現する複数の関数構造体が格納される。この別の 実施例では、プログラムパーザ７０４は関数構造体を一つ取り出しては、取り出 した関数構造体を動的検査エンジン７０６に送る働きをする。プロセスはステッ プ９０６（第９図）からステップ９０８に進む。 ステップ９０８において、リソースチェッカ６０２の一部である動的検査エン ジン７０６（第７図）によって、“サブジェクト関数（subjectfunction）”、 即ちステップ９０６（第９図）においてプログラムパーザ７０４によって動的検 査エンジン７０６に送られた関数構造体によって表される関数、の解析がなされ る。言い換えると、サブジェクト関数の実行の結果コンピュータプログラム６１ ０によって使用されるリソースに生じる効果が求められ、サブジェクト関数の実 行によって影響され る各リソースの状態遷移が解析される。これについては後により詳細に説明する 。ステップ９０４において初期化された関数モデルが、サブジェクト関数のエク スターナル、リソースの状態及び状態遷移を解析するのに用いられる。検出され た状態違反はプログミングエラーとして通知される。 サブジェクト関数の挙動が、そのエクスターナル及びリソースに関して定めら れると、モデルパーザ７０２はモデル記述ファイル６０４内にサブジェクト関数 の挙動を記述する関数モデルを形成し格納する。ステップ９０８（第９図）につ いては、論理流れ図９０８（第２４図）を参照して後により詳細に説明する。 プロセスは、ステップ９０８（第９図）からテストステップ９１０に進み、そ こでプログラムパーザ７０４（第７図）は更にコンピュータプログラム６１０（ 第６図）をパージングして、コンピュータプログラム６１０に、ステップ９０８ （第９図）に基づいて動的検査エンジン７０６（第７図）によって解析されるべ き関数がまだ含まれているかどうか判定する。上述した別の実施例では、プログ ラムパーザ７０４（第６図）は、ステップ９０８（第９図）に基づいて動的検査 エンジン７０６（第７図）によって解析されなければならないコンピュータプロ グラム６１０の関数を表す関数構造体がまだあるかどうか判定する。動的検査エ ンジン７０６（第７図）がまだ処理していないコンピュータプログラム６１０の 関数を表す関数構造体がある場合、プロセスはステップ９０６（第９図）に進み 、そこでプログラムパーザ７０４（第６図）は、その関数構造体を上述したよう に動的検査エンジン７０６（第７図）に送る。動的検査エンジン７０６（第７図 ）がコンピュータプログラム６１０の関数を表す関数構造体を全て処理し終わっ ている場合は、プロセスは論理流れ図９００に従って終了する（第９図）。モデルの初期化 論理流れ図９００のステップ９０４（第９図）を参照して上述したように、関 数の挙動を記述する関数モデルは初期化される。ステップ９０４を、論理流れ図 ９０４（第１０図）に詳細に示す。プロセスはステップ１００２において開始さ れ、上述したような関数モデルを含むモデル記述ファイル６０４（第６図）が開 かれる。 一実施例では、関数モデルはテキスト形式で格納され、読み込まれ、そしてメ モリ１０４（第１図）内の後に詳述するデータ構造内に格納される。関数モデル は、関数を識別する情報と、関数のエクスターナルに対するエクスターナルモデ ルのシングルリンクトリスト（singly-linkedlist）とを含む。関数を識別する 情報には（ｉ）関数名、（ｉｉ）関数が定義されているソースコードファイルの 名前、（ｉｉｉ）関数の定義が始まるソースコードファイル中のテキストライン の番号、及び（ｉｖ）関数の簡単な説明が含まれる。ソースコードファイルは、 メモリ１０４（第１図）（通常、磁気ディスクのような二次記憶装置）に格納さ れた、コンピュータプログラム６１０のようなコンピュータプログラムを格納す るファイルである。シングルリンクトリストの形態で格納されたエクスターナル モデルは、関数の実行が関数のエクスターナルに与える影響を、これらのエクス ターナルに施される演算と、それらのエクスターナルに関連して生成されるリソ ースとに関して定めるものである。 エクスターナルモデルは、エクスターナルの型を特定する情報、エクスターナ ルを識別する情報、及び関数の実行がエクスターナルに与える影響を定める情報 を含む。エクスターナルを識別する情報は、エクスターナルがパラメータの場合 はパラメータ番号（parameter number）、エクスターナルがグローバルまたはス タティック変数の場合は変数名、エクスターナルが戻り値項目である場合はＮＵ ＬＬである。関数の実行が エクスターナルに与える影響を定める情報には、（ｉ）エクスターナルに施され る演算のリスト、（ｉｉ）エクスターナルに関連して新たなリソースが生成され るかどうかを示すフラグ、及び（ｉｉｉ）新たなリソースが生成される場合、そ の新たなリソースの初期状態が含まれる。 モデル記述ファイル６０４（第６図）に格納されているモデルのテキスト書式 は、以下の“Backus-Naur Form（ＢＮＦ）”定義（８）に従う。“Backus-Naur Form”は形式的言語を記述するためのよく知られた書式である。 関数モデルは、テキスト書式においては、ＢＮＦ定義（８）のノンターミナル ＜ｆｕｎｃｔｉｏｎ−ｓｐｅｃ＞によって表される。ＢＮＦにおいて、ターミナ ル（terminal）とは、ある特定のＢＮＦ定義においてそれ以上拡張されない項目 であり、一方ノンターミナル(non-terminal)とは更に拡張される項目である。タ ーミナル＜ｆｕｎｃｔｉｏｎ−ｎａｍｅ＞は、関数に割り当てられる識別予、即 ち関数モデルによって表された関数を他の関数が呼び出すとき使用する識別子で ある。ターミナル＜ｆｕｎｃｔｉｏｎ−ｎａｍｅ＞は、関数の定義に使われるコ ンピュータ言語において有効な関数識別子であればどのようなものでもよい。タ ーミナル＜ｄｅｆｉｎｉｎｇ−ｆｉｌｅ＞は、関数の定義がなされるソースコー ドファイルを英数字で識別するものである。このような英数字による識別として 、例えばソースコードファイルのパスを記述してもよい。ターミナル＜ｄｅｆｉ ｎｉｎｇ−ｌｉｎｅ＞は、負でない数字、即ち０乃至９の数字を用いたテキスト 表現によって、ターミナル＜ｄｅｆ ｉｎｉｎｇ−ｆｉｌｅ＞によって識別されるソースコードファイルのどのテキス トラインにおいてモデル化される関数の定義が始まるのかを特定するものである 。 ＢＮＦでは、オプション項目は、角型括弧（“[]”）で囲って表される。従っ て、ターミナル＜ｆｕｎｃｔｉｏｎ−ｐｒｅｆｉｘ＞、ターミナル＜ｄｅｆｉｎ ｉｎｇ−ｆｉｌｅ＞、＜ｄｅｆｉｎｉｎｇ−ｌｉｎｅ＞、及び＜ｄｅｓｃｒｉｐ ｔｉｏｎ＞は、オプションである。また、連続したスラッシュ記号（“／／”） はコメント文の開始を表すものであり、これらのスラッシュ、及びこれらのスラ ッシュの後にそのテキストラインの最後まで続くテキスト文は、ＢＮＦ定義の一 部とはみなされないことに注意されたい。 ＢＮＦ定義（８）のターミナル＜ｄｅｓｃｒｉｐｔｉｏｎ＞は、１または複数 のキャラクタ（即ち、文字、数字、及び／またはシンボル）の並びである。ター ミナル＜ｄｅｓｃｒｉｐｔｉｏｎ＞はリソースチェッカ６０２（第６図）によっ ては使用されないが、テキスト書式で表されたモデルを読むユーザの便宜及び理 解のために提供されるものである。ＢＮＦ定義（８）のターミナル＜ｐａｒａｍ −ｎｕｍｂｅｒ＞は、０乃至９の数字を用いた負でない整数のテキスト表現であ り、パラメータリスト中の特定のパラメータを指定するものである。パラメータ ゼロが、関数の呼び出しにおけるパラメータリストの中の最初の、即ち最も左側 のパラメータである。後続のパラメータには順番に番号が付される。ＢＮＦ定義 （８）のターミナル＜ｖａｒ−ｎａｍｅ＞は、変数の識別子である。 モデル記述ファイル６０４（第６図）から抽出される関数モデルは、それぞれ 、各関数の実行がその関数のエクスターナルに及ぼす影響を記述する。プロセス はステップ１００２（第１０図）からループステップ １００４に進み、モデル記述ファイル６０４（第６図）に格納されている各関数 モデルは、ループステップ１００４（第１０図）とＮＥＸＴステップ１００４と によって定められるループに従って取り出され処理される。ループの各繰り返し において、処理されている関数モデルは、現関数モデル（current function mod el）と呼ばれる。ループステップ１００４とＮＥＸＴステップ１０１４とによっ て定められるループに従って、モデル記述ファイル中に格納された全ての関数モ デルの処理が完了すると、プロセスはループステップ１００４からステップ１０ ０６に進み、モデル記述ファイル６０４（第６図）は閉じられ、論理流れ図９０ ４（第１０図）に基づくプロセスは終了する。 モデル記述ファイルから取り出される各関数モデルに対し、プロセスはループ ステップ１００４からステップ１００８に進み、そこで上述したＢＮＦ定義（８ ）のノンターミナル＜ｆｕｎｃｔｉｏｎ−ｐｒｅｆｉｘ＞に対応する現関数モデ ルの一部が、現関数モデルから分離される。プロセスはステップ１０１０に進み 、そこで関数モデル構造体が初期化されて、ステップ１００８において現関数モ デルから分離された情報が関数モデル構造体に格納される。 関数モデル構造体１１００（第１１図）は、フィールド“ｎａｍｅ”１１０２ 、フィールド“ｆｉｌｅ”１１１０、フィールド“ｌｉｎｅ”１１１２、及びフ ィールド“ｄｅｓｃｒｉｐｔｉｏｎ”１１０８を含んでいる。ＢＮＦ定義（８） のターミナル＜ｆｕｎｃｔｉｏｎ−ｎａｍｅ＞、＜ｄｅｆｉｎｉｎｇ−ｆｉｌｅ ＞、＜ｄｅｆｉｎｉｎｇ−ｌｉｎｅ＞、及び＜ｄｅｓｃｒｉｐｔｉｏｎ＞（これ らは全てノンターミナル＜ｆｕｎｃｔｉｏｎ−ｐｒｅｆｉｘ＞の部分である）に 対応する関数モデルの部分が関数モデルから抽出され、関数モデル構造体１１０ ０のフィールド“ｎａｍｅ”１１０２、フィールド“ｆｉｌｅ”１１１０、フィ ールド“ｌｉｎｅ”１１１２、及びフィールド“ｄｅｓｃｒｉｐｔｉｏｎ”１１ ０８にそれぞれ格納される。プロセスはステップ１０１０（第１０図）からルー プステップ１０１２に進む。 ループステップ１０１２とＮＥＸＴステップ１０２８とによってループが定め られており、その各繰返しにおいて、上述したＢＮＦ定義（８）のノンターミナ ル＜ｅｘｔｅｒｎ−ｌｉｓｔ＞に対応する関数モデルの部分に示されたエクスタ ーナルの処理がなされる。ループステップ１０１２とＮＥＸＴステップ１０２８ とによって定められたループの各繰返しにおいて処理されているエクスターナル は、サブジェクトエクスターナルと呼ばれる。現関数モデル中に定められた全エ クスターナルの処理がループステップ１０１２とＮＥＸＴステップ１０２８とに よって定められたループに従って終了すると、プロセスはループステップ１０１ ２からＮＥＸＴステップ１０１４へ進む。プロセスはＮＥＸＴステップ１０１４ からループステップ１００４へと進み、モデル記述ファイル６０４（第６図）か ら取り出された別の関数モデルが更に処理されるか、あるいは全ての関数モデル が処理されている場合は、上述したように、プロセスはステップ１００６（第１ ０図）へと進む。 ＢＮＦ定義（８）のノンターミナル＜ｅｘｔｅｒｎ−Ｉｉｓｔ＞に対応する現 関数モデルの部分に示された各エクスターナルに対し、プロセスはループステッ プ１０１２からステップ１０１６へと進む。ステップ１０１６では、例えばエク スターナルモデル構造体１２００（第１２図）のような、新たなエクスターナル モデル構造体が生成される。 エクスターナルモデル構造体１２００は、フィールド“ｅｑｕｉｖａｌｅｎｔ ”１２０２、フィールド“ｔｙｐｅ”１２０４、フィールド“ｐａｒａｍｅｔｅ ｒ ｎｕｍｂｅｒ”１２０６、フィールド“ｎａｍｅ”１２０８、フィールド“ ｎｅｘｔ”１２１０、フィールド“ｎｕｍｂｅ ｒ ｏｆ ｏｐｅｒａｔｉｏｎｓ”１２１２、フィールド“ｏｐｅｒａｔｉｏｎ ｓ”１２１４、フィールド“ｎｅｗ ｒｅｓｏｕｒｃｅ”１２１８、フィールド “ｉｎｉｔｉａｌ ｓｔａｔｅ”１２２０、及びフィールド“ｄｅｓｃｒｉｐｔ ｉｏｎ”１２２２を含んでいる。ステップ１０１６（第１０図）では、ＢＮＦ定 義（８）のノンターミナル＜ｅｘｔｅｒｎａｌ＞の定義内のターミナル＜ｐａｒ ａｍ−ｎｕｍｂｅｒ＞に対応するサブジェクトエクスターナルモデルの部分が、 サブジェクトエクスターナルモデルから取り出され、エクスターナルモデル構造 体１２００のフィールド“ｐａｒａｍｅｔｅｒ ｎｕｍｂｅｒ”１２０６（第１ ２図）に格納される。 一実施例では、フィールド“ｅｑｕｉｖａｌｅｎｔ”１２０２が用いられて、 第２のエクスターナルモデル構造体が特定される。そうすることによって、エク スターナルモデル構造体１２００が、第２のエクスターナルモデル構造体に関係 付けられる。例えば、関数の戻り値項目が第１パラメータである場合、そのよう にすることが適切であろう。本明細書中に開示する実施例では、フィールド“ｅ ｑｕｉｖａｌｅｎｔ”１２０２は使用されず、従ってこのフィールドはＮＵＬＬ 値に初期化される。ステップ１０１６（第１０図）から、プロセスはステップ１ ０１８へと進む。 ステップ１０１８では、サブジェクトエクスターナルモデルによって表された エクスターナルの型を定める、ＢＮＦ定義（８）のノンターミナル＜ｅｘｔｅｒ ｎ−ｔｙｐｅ＞に対応するサブジェクトエクスターナルモデルの部分が、サブジ ェクトエクスターナルモデルから抽出される。上記のＢＮＦ定義（８）に示され ているように、エクスターナルモデルによって表されるエクスターナルは、戻り 値項目、パラメータ、あるいはグローバル定義／スタティック変数であり得る。 サブジェクトエクス ターナルモデルによって表されたエクスターナルの型を示すデータは、エクスタ ーナルモデル構造体１２００のフィールド“ｔｙｐｅ”１２０４（第１２図）に 格納される。プロセスはステップ１０１８（第１０図）からループステップ１０ ２０へと進む。 上記のＢＮＦ定義（８）に示されているように、関数の実行は、その関数の各 エクスターナルに１または複数の影響または“結果(result)”を与え得る。各結 果はＢＮＦ定義（８）においてノンターミナル＜ｒｅｓｕｌｔ＞として表される 。１または複数の結果がノンターミナル＜ｒｅｓｕｌｔ−ｌｉｓｔ＞に含まれる 。ループステップ１０２０とＮＥＸＴステップ１０２４とによって定められるル ープにおいて、サブジェクトエクスターナルモデルのノンターミナル＜ｒｅｓｕ ｌｔ−ｌｉｓｔ＞のリスト内の各結果の処理がなされる。ループステップ１０２ ０とＮＥＸＴステップ１０２４とによって定められるループの繰返しにおいて、 処理されている結果を、処理対象結果（subject result）と呼ぶ。以下に述べる ように、サブジェクトエクスターナルモデルの全ての結果をループステップ１０ ２０とＮＥＸＴステップ１０２４とによって定められるループに基づいて処理す ると、プロセスはループステップ１０２０からステップ１０２６へ進む。 サブジェクトエクスターナルモデルに対する各結果に対し、プロセスはループ ステップ１０２０からステップ１０２２に進む。ステップ１０２２において、処 理対象結果がサブジェクトエクスターナルモデルから抽出される。この結果は、 エクスターナルモデル構造体１２００（第１２図）のようなエクスターナルモデ ル構造体に格納される。例えば、上記で定義した関数モデル（３）は、第１エク スターナル、即ち戻り値項目に対し１つの結果を、第２エクスターナル、即ちパ ラメータ０に対し１つの結果を定めている。戻り値項目の結果は‘（ｎｅｗ Ｑ “ｍｅ ｍｏｒｙ”）’と定められており、戻り値項目に対し新たなリソースが生成され ること、そのリソースの初期状態は状態Ｑであることが示され、更に、そのリソ ースの簡単な説明として“ｍｅｍｏｒｙ（メモリ）”が与えられている。従って 、この戻り値項目に対するエクスターナルモデルをエクスターナルモデル構造体 １２００が表現する場合、（ｉ）フィールド“ｎｅｗ ｒｅｓｏｕｒｃｅ”１２ １８が“ｔｒｕｅ”のブール値に設定され、新たなリソースが生成されることが 示され、（ｉｉ）新たなリソースの初期状態が状態Ｑであることを示すようにフ ィールド“ｉｎｉｔｉａｌ ｓｔａｔｅ”１２２０がセットされ、（ｉｉｉ）テ キスト“ｍｅｍｏｒｙ“がフィールド“ｄｅｓｐｒｉｐｔｉｏｎ”１２２２に格 納される。 第２の例として、上記の関数モデル（３）は、第２エクスターナル、即ちパラ メータ０に対して結果“(ｏｐ ｃ)”を定めている。結果“(ｏｐ ｃ)”は、エ クスターナルに演算Ｃが施されることを表す。従って、エクスターナルモデル構 造体１２００がパラメータ０に対するエクスターナルモデルを表す場合、初期値 として０を有するフィールド“ｎｕｍｂｅｒ ｏｆ ｏｐｅｒａｔｉｏｎｓ”１ ２１２がインクリメント（１増加）され、演算識別子“ｃ”が、フィールド“ｎ ｕｍｂｅｒ ｏｆ ｏｐｅｒａｔｉｏｎｓ”１２１２によって示される位置に対 応するフィールド“ｏｐｅｒａｔｉｏｎｓ”１２１４に格納される。この例では 、フィールド“ｎｕｍｂｅｒ ｏｆ ｏｐｅｒａｔｉｏｎｓ”１２１２は値１を 格納し、フィールド“ｏｐｅｒａｔｉｏｎｓ”１２１４内の最初の演算識別子は 演算ｃの識別子となる。もし、第２の演算が第２のエクスターナルに施されると すると、フィールド“ｎｕｍｂｅｒ ｏｆ ｏｐｅｒａｔｉｏｎｓ”１２１２は もう一度インクリメントされ値２となり、フィールド“ｏｐｅｒａｔｉｏｎｓ” １２１４内の第２の演算識別 子が第２の演算の識別子となる。 プロセスはステップ１０２２（第１０図）からＮＥＸＴステップ１０２４を介 して上述したループステップ１０２０へ戻る。上述したようにプロセスは、サブ ジェクトエクスターナルモデルに対する全ての結果の処理が終了すると、ループ ステップ１０２０からステップ１０２６に進む。 ステップ１０２６では、サブジェクトエクスターナルモデルを表すエクスター ナルモデル構造体が、現関数モデル構造体内のエクスターナルのシングルリンク トリストに加えられる。上記の関数モデル（３）の文脈において説明する。まず 、関数モデル構造体１１００Ａのフィールド“ｆｉｒｓｔ ｅｘｔｅｒｎａｌ” １００４Ａ及び“ｌａｓｔ ｅｘｔｅｒｎａｌ”１１０６Ａにエクスターナルモ デル構造体１２００Ａを指定するポインタを格納することによって、エクスター ナルモデル構造体１２００Ａ（第１３図）が関数モデル構造体１１００Ａに付け 加えられる。続いて、エクスターナルモデル構造体１２００Ａのフィールド“ｎ ｅｘｔ”１２１０Ａ及び関数モデル構造体１１００Ａのフィールド“ｌａｓｔ ｅｘｔｅｒｎａｌ”１１０６Ａに、第１３図に示すようにエクスターナルモデル 構造体１２００Ｂを指すポインタを格納する（フィールド“ｌａｓｔ ｅｘｔｅ ｒｎａｌ”１１０６Ａに前に格納されたポインタは取って代わられる）ことによ って、第２エクスターナルモデル構造体１２００Ｂが関数モデル構造体１１００ Ａに加えられる。 プロセスはステップ１０２６（第１０図）からＮＥＸＴステップ１０２８を介 してループステップ１０１２へと進む。上述したように、全エクスターナルモデ ルが処理されていると、プロセスはループステップ１０１２からＮＥＸＴステッ プ１０１４を介してループステップ１００４へ進む。上述したように、全関数モ デルの処理が終了していると、プロ セスはループステップ１００４からステップ１００６へ進み、上述したようにテ キストフォーマットで記載された関数モデルを含むファイルが閉じられる。論理 流れ図９０４に基づくプロセスは、ステップ１００６の後終了する。関数の内部表現 プログラムパーザ７０４（第７図）によってコンピュータプログラム６１０（ 第６図）のパージングがなされると、コンピュータプログラム６１０はメモリ１ ０４において一連の関数構造体によって表される。上述した別の実施例では、プ ログラムパーザ７０４は、コンピュータプログラム６１０から、例えばＣ言語の ような特定のコンピュータ言語に従うソースコンピュータプログラムを予めパー ジングすることによって形成された関数構造体を取り出す働きをする。ソースコ ンピュータプログラムはソースコードプリプロセッサによってパージングされる が、このソースコードプリプロセッサは、ソースコンピュータプログラムが従う コンピュータ言語に基づいてソースコンピュータプログラムのパージングを行い 、コンピュータプログラム６１０中にソースコンピュータプログラム内に定義さ れた関数を表す関数構造体を形成し格納するものである。このソースコードプリ プロセッサ（図示せず）はリソースチェッカ６０２とは別個のコンピュータプロ セスである。 この別の実施例では、ソースコードプリプロセッサはマサチューセッツ州、ケ ンブリッジ（Cambridge，Massachusetts）の“Free Software Foundation，Inc ”から入手可能な“GNU C Compiler”に基づくものである。本明細書の一部であ り、全体が本出願に引証として含まれる付録Ｂとして示されているコンピュータ 命令のリストは、抽出されたコンピュータプログラムの関数を、ソースコードプ ロセッサから、抽出された関数を表すための後に詳述するデータ構造へと移すた めのデータ構造及 び関数を定義したものである。一実施例では、公知の上記した“GNU C Compiler ”のような従来のコンパイラが用いられてコンピュータプログラムのパージング がなされ、パージングされたプログラムは、付録Ｂに定義されているようなデー タ構造中に表される。 以下に、関数構造体について説明する。関数構造体内のフィールド及び関係に ついて理解を深めることによって、以下の動的検査エンジン７０６（第７図）の 処理に対する説明がより容易となる。 関数構造体１４００（第１４図）は、コンピュータプログラム６１０、または 上述したような別の実施例ではソースコードプログラム、によって定められた関 数を表すものであり、（ｉ）フィールド“ｎａｍｅ“１４０２、（ｉｉ）フィー ルド“ｌｉｎｅ”１４０４、（ｉｉｉ）フィールド“ｆｉｌｅ”１４０６、（ｉ ｖ）フィールド“ｒｅｓｕｌｔ”１４０８、（ｖ）フィールド“ｅｘｔｅｒｎａ ｌｓ”１４１０及び（ｖｉ）フィールド“ｓｔａｔｅｍｅｎｔ”を含んでいる。 関数構造体１４００のフィールド“ｎａｍｅ”１４０２は、関数構造体１４００ によって表される関数の識別予を特定する。例えば、上記のソースコード抜粋（ １）の関数ｅｘａｍｐｌｅ １ () の識別子は“ｅｘａｍｐｌｅ １”である。 フィールド“ｆｉｌｅ”１４０６及びフィールド“ｌｉｎｅ”１４０４は、そ れぞれ、関数構造体１４００によって表される関数が定義されるソースコードフ ァイル及びそのファイル内のライン番号を示す。例えば、上記のソースコード抜 粋（１）が、ファイル名“ｅｘａｍｐｌｅ １．ｃ”のソースコードファイルの 全内容であるとした場合、関数ｅｘａｍｐｌｅ １ () を表す関数構造体のフィ ールド“ｆｉｌｅ”１４０６及びフィールド“ｌｉｎｅ”１４０４は、それぞれ 、テキスト“ｅｘａｍｐｌｅ １．ｃ”及び整数値７のデータを格納する。 フィールド“ｒｅｓｕｌｔ”１４０８は、宣言構造体１４１８を指定する。こ の宣言構造体１４１８は、以下に述べる宣言構造体１５０６と同様であり、関数 構造体１４００によって表される関数がリターンする結果（ｒｅｓｕｌｔ）の型 を規定する。例えば、上記のソースコード抜粋（１）の関数ｅｘａｍｐｌｅ １ () は、ソースコード抜粋（１）のライン７に示されているように、整数型の結 果をリターンする。即ち、型“ｉｎｔ”のデータをリターンする。従って、関数 構造体１４００が関数ｅｘａｍｐｌｅ １ () を表す場合、フィールド“ｒｅｓ ｕｌｔ”１４０８は、整数データを規定する宣言構造体１４１８を指定する。 関数構造体１４００のフィールド“ｅｘｔｅｒｎａｌｓ”１４１０は、後によ り詳細に説明するエクスターナルリスト構造体１４１４を指定するポインタであ る。後に詳述するように、エクスターナルリスト構造体１４１４のようなエクス ターナルリスト構造体は、複数のエクスターナルリスト構造体をシングルリンク トリスト（singly-linked list）を形成するようにリンクするのに用いられるポ インタを含んでいる。従って、リストの長さが１の場合も含み、一つのエクスタ ーナルリスト構造体を指定することは、エクスターナルリスト構造体のシングル リンクトリストを指定することである。関数構造体１４００のフィールド“ｅｘ ｔｅｒｎａｌｓ”１４１０によって指定されるこのようなシングルリンクトリス トは、関数構造体１４００によって表される関数のエクスターナルを表すエクス ターナルリスト構造体を含む。 関数構造体１４００のフィールド“ｆｉｒｓｔ ｓｔｍｔ”１４１２は、後に より詳細に説明するステートメント構造体１４１６を指定するポインタである。 後により詳細に説明するように、ステートメント構造体１４１６のようなステー トメント構造体は、複数のステートメント構造体をシングルリンクトリストを形 成するようにリンクするのに用いら れるポインタを含んでいる。従って、リストの長さが１の場合も含み、一つのス テートメント構造体を指定することは、ステートメント構造体のシングルリンク トリストを指定することである。関数構造体１４００のフィールド“ｆｉｒｓｔ ｓｔｍｔ”１４１２によって指定されるこのようなシングルリンクトリストは 、関数構造体１４００によって表される関数のステートメントを表すステートメ ント構造体を含む。エクスターナルリスト構造体 エクスターナルリスト構造体１４１４を第１５図に詳細に示す。エクスターナ ルリスト構造体１４１４は、関数構造体１４００（第１４図）によって表される 関数のエクスターナルを表すものであり、フィールド“ｆｉｒｓｔ ｄｅｃｌ” １５０２（第１５図）、フィールド“ｎｅｘｔ”１５０４、及びフィールド“ｆ ｉｒｓｔ ｅｘｔｅｒｎａｌ”１５１０を含んでいる。フィールド“ｆｉｒｓｔ ｄｅｃｌ”１５０２は、後により詳細に説明するように、エクスターナルリス ト構造体１４１４によって表されるエクスターナルのデータ型を規定する宣言構 造体１５０６を指定するポインタである。フィールド“ｎｅｘｔ”１５０４は、 エクスターナルのシングルリンクトリストにおいてエクスターナルリスト構造体 １４１４のすぐ後にエクスターナルリスト構造体１５０８が続く場合、エクスタ ーナルリスト構造体１５０８を指定するポインタである。エクスターナルリスト 構造体のシングルリンクトリストにおいてエクスターナルリスト構造体１４１４ に続くエクスターナルリスト構造体がない場合、エクスターナルリスト構造体１ ４１４のフィールド“ｎｅｘｔ”１５０４はＮＵＬＬとなる。即ち、ＮＵＬＬデ ータを含む。フィールド“ｆｉｒｓｔ ｅｘｔｅｒｎａｌ”１５１０は、後によ り詳細に説明するように、エクスターナルリスト構造体１４１４によって表され るエクスターナルの状態を示すエクスターナル状態構造体（図示せず） を指定するポインタである。宣言構造体 宣言構造体１５０６を第１６図に詳細に示す。宣言構造体は、宣言される変数 または関数、即ち宣言において規定される変数または関数を規定する構造体であ る。Ｃ言語の文脈中の宣言については周知であり、Ｃスタンダードにも示されて いる。宣言構造体１５０６は、フィールド“ｋｉｎｄ”１６０２、フィールド“ ｎａｍｅ”１６０４、フィールド“ｔｙｐｅ”１６０６、フィールド“ｉｔｅｍ ”１６０８、及びフィールド“ｍｏｄｅｌ”１６１０を含んでいる。 フィールド“ｋｉｎｄ”１６０２は、宣言される項目または関数が、グローバ ルに定義されるものであるか、スタティックなものであるか、あるいはローカル に定義されるものであるかを示すデータを含む。フィールド“ｎａｍｅ”１６０ ４は、項目または関数の識別子を特定するテキストデータを含む。上述したよう に、Ｃ言語の文脈において、項目または関数はテキスト形式の識別子によって識 別され、識別子はＣスタンダードのセクション６．１．２に述べられているよう な所定の書式に従わなければならない。 宣言構造体１５０６のフィールド“ｔｙｐｅ”１６０６は、宣言される項目ま たは関数によって表されるデータの特定の型を定める型構造体１６１２を指定す るポインタである。型構造体１６１２については、後で説明する。フィールド“ ｉｔｅｍ”１６０８は、宣言される項目を表す項目構造体２７００を指定するポ インタである。宣言構造体１５０６が宣言される関数を表現する場合、フィール ド“ｉｔｅｍ”１６０８はＮＵＬＬであり、従って項目構造体は指定されない。 宣言構造体１５０６のフィールド“ｍｏｄｅｌ”１６１０は、宣言構造体１５ ０６が関数の宣言を表し、その関数のモデルが関数モデル構造 体１１００によって表される場合、関数モデル構造体１１００を指定するポイン タである。宣言構造体１５０６が関数の宣言を表さない場合、フィールド“ｍｏ ｄｅｌ”１６１０はＮＵＬＬであり、即ち、ＮＵＬＬデータを含む。従って関数 モデル構造体は指定されない。また、宣言構造体１５０６が関数の宣言を表すが 、その関数の関数モデル構造体が存在しない場合も、フィールド“ｍｏｄｅｌ” １６１０はＮＵＬＬとなる。型構造体 第１７図に型構造体１６１２を詳細に示す。型構造体１６１２のような型構造 体は、整数、浮動小数点、英数文字、及び構造体のようなユーザ定義による型、 のような特定のデータ型を規定する。型構造体１６１２は、フィールド“ｋｉｎ ｄ”７０２、フィールド“ｎａｍｅ”１７０４、フィールド“ｓｉｚｅ”１７０ ６、フィールド“ｐｏｉｎｔｓ ｔｏ”１７０８、及びフィールド“ｆｉｅｌｄ ｓ”１７１０を含んでいる。フィールド“ｋｉｎｄ”１７０２は、型構造体１６ １２によって表される型が、整数、実数（即ち浮動小数点数値データ）、ポイン タ、配列、構造体（即ち、Ｃ言語に対しデータ型“ｓｔｒｕｃｔ”で定義された もの）、あるいはユニオン（union）のいずれであるか特定するデータを含む。 これらの各型は公知であり、Ｃスタンダードのセクション６．１．２．５及び６ ．５以降に述べられている。 型構造体１６１２のフィールド“ｎａｍｅ”１７０４は、型構造体１６１２に よって表される型がユーザ定義されるものである場合、その型の識別子を特定す る英数字データを含む。型構造体１６１２によって表される型がＣ言語によって 予め定められたものである場合、フィールド“ｎａｍｅ”１７０４はＮＵＬＬで ある。 フィールド“ｓｉｚｅ”１７０６は、型構造体１６１２によって表される型の サイズを規定する。型が配列でない場合、フィールド“ｓｉｚ ｅ”１７０６は、型構造体１６１２によって表される型の項目に含まれるデータ のビット数を示す。例えば、型が３２ビット整数の場合、型構造体１６１２のフ ィールド“ｓｉｚｅ”１７０６は値３２を示す。型が配列の場合、フィールド“ ｓｉｚｅ”１７０６は配列全体に含まれるデータのビット数、即ちその配列のエ レメントによって表されるその型の項目に含まれるデータのビット数にその配列 全体に含まれるエレメントの数を掛けたものを表す。例えば、宣言“ｉｎｔ ａ ｒｒａｙ[１０]；”によって、１０個のエレメントからなる配列が宣言されると する。型“ｉｎｔ”が３２ビット整数の場合、宣言された配列のサイズは、１０ エレメント×３２ビットとなる。従って、その配列のサイズは３２０ビットとな る。 構造体１６１２によって表される型が別のデータ型を指定するポインタの場合 、フィールド“ｐｏｉｎｔｓ ｔｏ”１７０８は別のデータ型を表す型構造体、 即ち型構造体１７１２を指定するポインタである。型構造体１７１２は型構造体 １６１２と同様である。逆に、型構造体１６１２によって表される型がポインタ でない場合、フィールド“ｐｏｉｎｔｓ ｔｏ”１７０８はＮＵＬＬとなる。 型構造体１６１２によって表される型が構造体型(即ちＣ言語の型“ｓｔｒｕ ｃｔ”）またはユニオン型の場合、フィールド“ｆｉｅｌｄｓ”１７１０は、そ れぞれ、その構造体型またはユニオン型の第１フィールドを表すフィールド構造 体１７１４を指定するポインタとなる。後により詳細に説明するように、ある特 定の構造体型またはユニオン型のフィールドに対応するフィールド構造体は、シ ングルリンクトリストを形成するようにリンクされる。型構造体１６１２によっ て表される型が構造体型でもユニオン型でもない場合、型構造体１６１２のフィ ールド“ｆｉｅｌｄｓ”１７１０はＮＵＬＬとなる。フィールド構造体 フィールド構造体１７１４を第１８図に詳細に示す。フィールド構造体１７１ ４は、フィールド“ｎａｍｅ”１８０２、フィールド“ｓｉｚｅ”１８０４、フ ィールド“ｏｆｆｓｅｔ”１８０６、及びフィールド“ｎｅｘｔ”１８０８を含 んでいる。フィールド構造体１７１４について、Ｃ言語に基づく以下の型定義の 例の文脈において説明する。 ソースコード抜粋（９）の型定義は、識別子が“ｐｏｉｎｔ”であり２つのフ ィールドを有する構造体型を定義している。型“ｐｏｉｎｔ”は従って構造体型 である。各フィールドは型“ｉｎｔ”であり、これは通常３２ビット整数である 。また、各フィールドは、識別子“ｘ”または“ｙ”を有している。 フィールド構造体１７１４のフィールド“ｎａｍｅ”１８０２は、フィールド 構造体１７１４によって表されるフィールドの識別子を特定する英数字データを 含む。例えば、ソースコード抜粋（９）に定義されている構造体の第１フィール ドを表すフィールド構造体のフィールド“ｎａｍｅ”はテキスト“ｘ”を含む。 フィールド構造体１７１４のフィールド“ｓｉｚｅ”１８０４は、フィールド 構造体１７１４によって表されるフィールドに含まれるデータのビット数を示す 。例えば、カリフォルニア州、マウンテンビュー（Mountain View）のサンマイ クロシステムズ社（Sun Microsystems,Inc.）から販売されている“SunOS C com piler”によってコンパイルされるようなＣ言語の典型的な例では、型“ｉｎｔ ”の項目は３２ビット長さである。ソースコード抜粋（９）の例では、各フィー ルドは３２ビット整数であり、従って３２ビットのデータを含む。従って、個々 のフィールドを表す各フィールド構造体のフィールド“ｓｉｚｅ”は整数値３２ を示す。 フィールド構造体１７１４のフィールド“ｏｆｆｓｅｔ”は、フィー ルド構造体１７１４によって表されるフィールドのデータまでの構造体の開始か らのオフセットを表す。例えば、ソースコード抜粋（９）におけるフィールド“ ｘ”は型“ｐｏｉｎｔ”の第１フィールドであるため、オフセットは０である。 型“ｐｏｉｎｔ”を第１９図に図式的に示す。型“ｐｏｉｎｔ”のフィールド“ ｘ”は３２ビット長さであり、オフセット０で始まる。型“ｐｏｉｎｔ”のフィ ールド“ｙ”は３２ビット長さであり、オフセット３２で始まる。従って、フィ ールド構造体１７１４Ｘ（これはフィールド構造体１７１４（第１８図）と全く 同様であり、型“ｐｏｉｎｔ”のフィールド“ｘ”を表すものである。）のフィ ールド“ｏｆｆｓｅｔ“１８０６Ｘ（第２０図）は、整数値０を示す。同様に、 フィールド構造体１７１４（第１８図）と全く同様な、型“ｐｏｉｎｔ”のフィ ールド“ｙ”を表すフィールド構造体１７１４Ｙのフィールド“ｏｆｆｓｅｔ” １８０６Ｙ（第２０図）は、整数値３２を示す。 フィールド構造体１７１４のフィールド“ｎｅｘｔ”１８０８（第１８図）は 、所与の構造体型のフィールド構造体のシングルリンクトリストにおける次のフ ィールド構造体を指定するポインタである。例えば、型“ｐｏｉｎｔ”を表す型 構造体１６１２Ｐのフィールド“ｆｉｅｌｄｓ”１７１０Ｐ（第２０図）は、型 “ｐｏｉｎｔ”の第１フィールドであるフィールド“Ｘ”を表すフィールド構造 体１７１０Ｘを指定する。型“ｐｏｉｎｔ”の次のフィールドはフィールド“Ｙ ”である。従って、フィールド構造体１７１４Ｘのフィールド“ｎｅｘｔ”１８ ０８Ｘは、型“ｐｏｉｎｔ”のフィールド“ｙ”を表すフィールド構造体１７１ ４Ｙを指定する。型“ｐｏｉｎｔ”のフィールド“ｙ”は、型“ｐｏｉｎｔ”の 最後のフィールドであり、その後に型“ｐｏｉｎｔ”の他のフィールドはない。 従って、フィールド構造体１７１４Ｙのフィールド“ｎｅｘｔ”１８１０ＹはＮ ＵＬＬである。ステートメント構造体 上述したように、関数構造体１４００のフィールド“ｆｉｒｓｔ ｓｔｍｔ” １４１２（第１４図）は、ステートメント構造体１４１６を指定する。ステート メント構造体１４１６は第２１図に詳細に示されている。ステートメント構造体 １４１６のようなステートメント構造体は、Ｃ言語に基づきまとまってある関数 を形成する複数のステートメントを表す。ステートメント１４１６は次のフィー ルドを含んでる：（ｉ）フィールド“ｋｉｎｄ”２１０２、（ｉｉ）フィールド “ｌｉｎｅ”２１０４、（ｉｉｉ）フィールド“ｎｅｘｔ”２１０６、（ｉｖ） フィールド“ｆｌａｇｓ”２１０８、及び（ｖ）フィールド“ｐｏｉｎｔｅｒｓ ”２１１０。 ステートメント構造体１４１６のフィールド“ｋｉｎｄ”２１０２は、ステー トメント構造体１４１６によって表されるステートメントの種類を表す。フィー ルド“ｋｉｎｄ”２１０２は、以下のステートメント種類のうちの１つを特定す る：エラー、宣言、式、ブロック、“ｉｆ”、“ｅｌｓｅ”、“ｒｅｔｕｒｎ” 、ループ、“ｓｗｉｔｃｈ”、“ｂｒｅａｋ”、“ｃｏｎｔｉｎｕｅ”、及び“ ｇｏｔｏ”。ステートメント構造体によるこれらのステートメント種類の各々の 表現について、以下により詳細に説明する。 ステートメント構造体１４１６のフィールド“ｌｉｎｅ”２１０４は、関数構 造体１４００（第１４図）によって表される関数を定義するソースコードファイ ル内において、ステートメント構造体１４１６によって表されるステートメント が現れる、即ち、ステートメント構造体１４１６によって表されるステートメン トを含むテキストラインを表す。ステートメントが現れるラインは、エラーを生 じさせる特定のステートメントが、検出されたエラーの通知によってユーザに特 定されるようにする ため、ステートメント構造体１４１６内に保持される。 ステートメント構造体１４１６のフィールド“ｎｅｘｔ”２１０６（第２１図 ）は、ステートメントのブロックにおいてステートメント構造体１４１６によっ て表されるステートメントのすぐ後に続くステートメントを表す別のステートメ ント構造体２１１２を指定するポインタである。このようにして、ステートメン トブロックの全ステートメントが、シングルリンクトリストを形成するようにリ ンクされたステートメント構造体によって表される。ステートメント構造体１４ １６（第２１図）によって表されるステートメントがステートメントブロックの 最後のステートメントの場合、フィールド“ｎｅｘｔ”２１０６はＮＵＬＬとな り、他のステートメント構造体を指定しない。 ステートメント構造体１４１６のフィールド“ｆｌａｇｓ”２１０８は符号な し３２ビット整数であり、その個々のビットはステートメント構造体１４１６に よって表されるステートメントに関連するエラーがユーザに通知されたかどうか を示すフラグとして用いられる。エラーが通知されるときにはいつも、通知され るべきエラーに対応するフィールド“ｆｌａｇｓ”２１０８のフラグがチェック される。フラグがセットされている場合、そのフラグはステートメント構造体１ ４１６によって表されるステートメントの文脈において既にそのエラーの通知が なされていることを表すため、エラーは通知されない。フラグがセットされてい ない場合は、エラーは通知され、エラーの通知を反映するようにフラグがセット される。このようにして、各タイプのエラーは、ある特定のステートメントに対 して１回だけ通知される。 ステートメント構造体１４１６のフィールド“ｐｏｉｎｔｅｒｓ”２１１０は 、ステートメント構造体１４１６によって表されるステートメントの各部分を表 す構造体を指定する１または複数のポインタの配列で ある。この配列中のポインタの数は、ステートメント構造体１４１６によって表 されるステートメントの特定の種類に依存する。 エラー、“ｂｒｅａｋ”、及び“ｃｏｎｔｉｎｕｅ”ステートメントは部分を 有さず、従ってステートメント構造体１４１６がエラー、“ｂｒｅａｋ”、ある いは“ｃｏｎｔｉｎｕｅ”ステートメントを表す場合、フィールド“ｐｏｉｎｔ ｅｒｓ”２１１０はＮＵＬＬである。エラーステートメントとは、Ｃ言語に従わ ないステートメントである。“ｂｒｅａｋ”及び“ｃｏｎｔｉｎｕｅ”ステート メントは周知であり、それぞれＣスタンダードのセクション６．６．６．３及び ６．６．６．２に説明されている。 宣言ステートメントには、特定の型のデータを有する宣言される変数が含まれ 、更に恐らくはその変数に対する初期値も含まれる。従って、ステートメント構 造体１４１６が宣言ステートメントを表す場合、フィールド“ｐｏｉｎｔｅｒｓ ”２１１０は２つのポインタからなる配列となる。第１のポインタは宣言される 変数を表す宣言構造体を指定する。初期値が定められる場合、第２のポインタは 、宣言される変数の初期値を与えるべく評価される式を表す式構造体を指定する 。宣言される変数に対し初期値が定められない場合は、第２のポインタはＮＵＬ Ｌである。 式ステートメント（expression statement）とは、それ自身が式であるステー トメントである。式（expression）はＣ言語の公知のコンポーネントであり、１ または複数の項目、関数に対する呼び出し、及び演算子の集まりである。Ｃ言語 では、全ての式は値（value）を有する。式の評価の結果は、値がその式の値で あるような項目となり、この項目はしばしば式の項目と呼ばれる。本明細書中で は、しばしば、式の項目の値を式の値と言う。式の評価については、以下により 詳細に説明される。 ステートメント構造体１４１６が式ステートメントを表す場合、フィ ールド“ｐｏｉｎｔｅｒｓ”２１１０は、式構造体２２００（第２２図）のよう な式構造体を指定する１つのポインタからなる配列となる。式構造体２２００は 、フィールド“ｋｉｎｄ”２２０２、フィールド“ｔｙｐｅ”２２０４、フィー ルド“ｉｔｅｍ”２２０６、フィールド“ｎｕｍ ｏｐｅｒａｎｄｓ”２２０８ 、及びフィールド“ｏｐｅｒａｎｄｓ”２２１０を含んでいる。フィールド“ｋ ｉｎｄ”２２０２は、式構造体２２００によって表される式の種類を特定する。 式が演算子を含む場合、フィールド“ｋｉｎｄ”２２０２はその演算子を示す。 フィールド“ｔｙｐｅ”２２０４は、式のデータ型、即ち、その式の評価の結 果を示す項目の型を表す型構造体２２１２を指定するポインタである。型構造体 ２２１２は、上述した型構造体１６１２と同様である。式構造体２２００のフィ ールド“ｉｔｅｍ”２２０６は、式の評価の結果を示す項目を表す項目構造体２ ２１４を指定するポインタである。項目構造体２２１４は上述した項目構造体２ ７００（第２７図）と同様である。式構造体２２００によって表された式の評価 の前においては、フィールド“ｉｔｅｍ”２２０６はＮＵＬＬである。 式構造体２２００によって表される式の中のオペランドの数はフィールド“ｎ ｕｍ ｏｐｅｒａｎｄｓ”２２０８によって示される。フィールド“ｏｐｅｒａ ｎｄｓ”２２１０は式構造体の配列であり、その各々は式構造体２２００によっ て表される式の一つのオペランドを表す。この配列の長さは、フィールド“ｎｕ ｍ ｏｐｅｒａｎｄｓ”２２０８に示されたオペランドの数に等しい。Ｃ言語に おいて定義される式の様々な型、及び各型の式のオペランドの数及び型について は周知であり、Ｃスタンダードにも記載されている。 ブロックステートメントとは、１または複数のステートメントをグループにま とめたステートメントである。ブロックステートメントの実行 は、１または複数のステートメントの実行である。ブロックステートメントは部 分、即ち、１または複数のステートメントを有する。ステートメント構造体１４ １６（第２１図）がブロックステートメントを表す場合、フィールド“ｐｏｉｎ ｔｅｒｓ”２１１０はシングルポインタであり、このポインタは１または複数の ステートメントの最初のステートメントを表すステートメント構造体を指定する 。１または複数のステートメントを表すステートメント構造体は、上述したよう にフィールド“ｎｅｘｔ”２１０６を用いることによってシングルリンクトリス トを形成するようにリンクされる。 “ｉｆ”ステートメントは、“ｉｆ”ステートメントの述語としばしば呼ばれ る式を評価して、その評価の結果が“ｔｒｕｅ”のブール値になる場合は、第２ のステートメントを実行させるものである。ステートメント構造体１４１６が“ ｉｆ”ステートメントを表す場合、フィールド“ｐｏｉｎｔｅｒｓ”２１１０は ２つのポインタからなる配列となる。第１のポインタは、その値によって第２ス テートメントが実行されるか否かが判定される式を表す式構造体を指定する。第 ２ポインタは、第２ステートメントを表すステートメント構造体を指定する。 “ｅｌｓｅ”ステートメントは、“ｉｆ”ステートメントのすぐ後に置かれ、 “ｉｆ”ステートメントの述語の評価が“ｆａｌｓｅ”のブール値なる場合、第 ３ステートメントを実行させる。ステートメント構造体１４１６が“ｅｌｓｅ” ステートメントを表す場合、フィールド“ｐｏｉｎｔｅｒｓ”２１１０は２つの ポインタからなる配列となる。第１ポインタは、第３ステートメントを表すステ ートメント構造体を指定する。第２ポインタは、ある式構造体を指定するかまた はＮＵＬＬである。この式構造体によって表される式は、しばしば、“ｅｌｓｅ ”ステートメントの述語と呼ばれる。第２ポインタが式構造体を指定する場合、 第 ３ステートメントは、“ｉｆ”ステートメントの述語の評価が“ｆａｌｓｅ”の ブール値となり、“ｅｌｓｅ”ステートメントの述語の評価が“ｔｒｕｅ”のブ ール値となる場合にのみ実行される。Ｃスタンダードにも記載され広く知られて いるように、これは“ｅｌｓｅ ｉｆ”ステートメントを表す。第２ポインタが ＮＵＬＬの場合、第３ステートメントは、“ｉｆ”ステートメントの述語の評価 が“ｆａｌｓｅ”のブール値となる場合にのみ実行される。 “ｒｅｔｕｒｎ”ステートメントは、被呼び出し関数の実行を終了させ、制御 を呼び出し関数に移すとともに、場合によっては呼び出し関数に戻り値項目を与 える。呼び出し関数に制御を移すとともに、呼び出し関数に戻り値項目を与える ことは、呼び出し関数に戻り値項目をリターンすると言われる。ステートメント 構造体１４１６が“ｒｅｔｕｒｎ”ステートメントを表す場合、フィールド“ｐ ｏｉｎｔｅｒｓ”２１１０はシングルポインタであり、このポインタは式構造体 を指定するかまたはＮＵＬＬである。このポインタが式構造体を指定する場合、 その式構造体によって表される式の評価の結果を示す項目が呼び出し関数にリタ ーンされる。 ループステートメントは、０回または１回以上実行される第２ステートメント を生成するものである。Ｃ言語におけるループステートメントの例として、“ｆ ｏｒ”ステートメント、“ｄｏ”ステートメント、及び“ｗｈｉｌｅ”ステート メントがあるが、それらはＣスタンダードのセクション６．６．５に記載されて おり広く知られている。ステートメント構造体１４１６がループステートメント を表す場合、フィールド“ｐｏｉｎｔｅｒｓ”２１１０はシングルポインタであ り、第２ステートメントを表すステートメント構造体を指定する。 “ｓｗｉｔｃｈ”ステートメントは、式を評価し、式の評価の結果を 示す値に応じてブロックステートメント内の制御をそのブロックステートメント 内の特定のステートメントへ移す。式は、しばしば“ｓｗｉｔｃｈ”ステートメ ントの述語と呼ばれる。ステートメント構造体１４１６が“ｓｗｉｔｃｈ”ステ ートメントを表す場合、フィールド“ｐｏｉｎｔｅｒｓ”２１１０は２つのポイ ンタからなる配列となる。第１のポインタは、その値に応じて制御が移行する式 を表す式構造体を指定する。第２のポインタは、ブロックステートメントを表す ステートメント構造体を指定する。 “ｇｏｔｏ”ステートメントは第２ステートメントへの制御の移行を発生させ る。一実施例では、ステートメント構造体１４１６が“ｇｏｔｏ”ステートメン トを表す場合、フィールド“ｐｏｉｎｔｅｒｓ”２１１０は、第２ステートメン トを表すステートメント構造体を指定するシングルポインタからなる配列である 。より簡略化された実施例では、“ｇｏｔｏ”ステートメントは被呼び出しルー チンの実行を終了させるものとして取り扱われる。この実施例では“ｇｏｔｏ” ステートメントは部分を有さず、フィールド“ｐｏｉｎｔｅｒｓ”２１１０はポ インタを含まない配列である。 このようにして、関数構造体１４００（第１４図）は動的検査エンジン７０６ によって解析されるべき関数を表現する。関数の解析 上述したように、動的検査エンジン７０６（第７図）は、ステップ９０８（第 ９図）においてコンピュータプログラム６１０（第６図）のパージングの結果得 られた各関数構造体を解析する。ステップ９０８は論理流れ図９０８（第２４図 ）に、より詳細に示されている。ステップ９０８の実行において、処理されてい る関数構造体はサブジェクト関数構造体と呼ばれる。同様に、サブジェクト関数 構造体によって表される関 数は、サブジェクト関数と呼ばれる。論理流れ図９０８のステップ２４０４及び ２４０８において、サブジェクト関数は様々な仮定のもとで解析される。 上記において詳しく説明したように、ある特定の関数の制御流れ経路は、しば しばその関数が実行されるまでは未知であるイベントに依存する。実行後でも、 その関数のある実行時に生じたイベントがその関数の全ての実行においても常に 発生するとは限らない。そのため、制御の流れが未知のイベントに依存するよう な関数の解析は、それらの未知のイベントについての様々な仮定の下で繰り返し なされる。 一実施例では、関数の全ての可能な制御流れが決定され解析される。例えば、 制御は、関数内の全ての“ｉｆ”ステートメントに対して２つの可能な経路の一 方に沿って流れ得るし、また、関数内の全ての“ｓｗｉｔｃｈ”ステートメント に対して複数の可能な経路の内の１つに沿って流れ得る。“ｓｗｉｔｃｈ”ステ ートメントの場合、可能な経路の数は、その“ｓｗｉｔｃｈ”ステートメントに 関連する“ｃａｓｅ”ステートメントの数に等しい。これには、存在する場合に は、“ｄｅｆａｕｌｔ”ステートメントも含まれる。いったん関数の全ての可能 な制御流れ経路が決定されると、その関数の各制御流れ経路が１回ずつ用いられ るようにして、その関数は繰り返し解析される。このようにして、その関数の制 御の流れに影響を与え得る全ての可能なイベントを考慮して関数の解析がなされ る。 より簡略化された実施例では、関数の特定の制御流れ経路がその関数内の各“ ｉｆ”ステートメント及び各“ｓｗｉｔｃｈ”ステートメントにおけるイベント に関してランダムな仮定を設定することによってランダムに選択される。関数は 様々な制御流れ経路がランダムに選択されるようにして繰り返し解析される。関 数を解析する回数は、関数の全ての 可能な制御流れ経路が解析される可能性が十分高くなるように選択されるか、あ るいは別の方法として１つのルーチンを解析するのに費やされる労力を制限する ように選択することもできる。 ステップ２４０４及び２４０８（第２４図）は、後者のより簡略化された方の 実施例を例示したものである。ステップ２４０４において、サブジェクト関数が 解析される回数が決定される。ステップ２４０４は、論理流れ図２４０４（第２ ５図）としてより詳細に示されている。ステップ２５０２において、サブジェク ト関数内で“ｉｆ”ステートメントが使用される回数が決定される。詳述すると 、実行エンジン８０２（第８図）によって、関数構造体１４００のフィールド“ ｆｉｒｓｔ−ｓｔａｔｅｍｅｎｔ”１４１２（第１４図）により直接的または間 接的に指定されたステートメント構造体のシングルリンクトリスト内の各ステー トメント構造体のフィールド“ｋｉｎｄ”２１０２（第２１図）が、“ｉｆ”ス テートメントを示すデータと比較される。ステートメント構造体のフィールド“ ｋｉｎｄ”と“ｉｆ”ステートメントを示すデータとが整合する回数が、“ｉｆ ”ステートメントがそのサブジェクト関数内で使用される回数として記録される 。 ステップ２５０２から、プロセスはステップ２５０４に進み、そこでサブジェ クト関数が解析される回数が決定される。一実施例では、サブジェクト関数が解 析される回数は、“ｉｆ”ステートメントがサブジェクト関数内で使用される回 数に対応する。その例を表Ｍに示す。 ステップ２５０４の後、論理流れ図２４０４に基づくプロセス、従ってステッ プ２４０４（第２４図）は、終了する。プロセスはステップ２４０４からステッ プ２４０８へ進み、サブジェクト関数は上述したステップ２４０４で決定された 数だけ繰り返し解析される。ステップ２４０８の一回の繰返し、即ち、サブジェ クト関数の１回の解析は、論理流れ図２６００（第２６図）に示される。 サブジェクト関数の１回の繰返しの解析は、ステップ２６０２で開始され、そ こで、各エクスターナルに対するエクスターナル状態構造体が初期化される。エ クスターナル状態構造体は、まずそのエクスターナル状態構造体に対応する、即 ちそのエクスターナル状態構造体によって表される状態を有するエクスターナル に対応する項目構造体を生成し、続いてそのエクスターナルのＤＫ及びＣＰ状態 を状態Ｏに設定することによって初期化される。項目構造体は、項目を表すメモ リ１０４（第１図）内の構造体である。 項目構造体２７００（第２７図）は、以下のフィールドを含んでいる。 即ち、フィールド“ｒｅｓｏｕｒｃｅ”２７０２、フィールド“ｅｘｔｅｒｎａ ｌ”２７０４、フィールド“ｖａｌｕｅ”２７０６、フィールドｆｉｒｓｔ ｉ ｎ ｂｕｎｃｈ２７０８、フィールド“ｓｉｚｅ ｏｆ ｂｕｎｃｈ”２７１０ 、フィールド“ｔｙｐｅ ｃｏｄｅ”２７１２、フィールド“ｉｎｉｔｉａｌｉ ｚｅｄ”２７１４、フィールド“ｈｅａｄ ｉｎ ｂｕｎｃｈ”２７１６、フィ ールド“ｋｎｏｗｎ ｂｕｎｃｈ ｓｉｚｅ”２７１８、及びフィールド“ｉｎ ｖａｌｉｄ ｐｏｉｎｔｅｒ”２７２０を含んでいる。 各項目は、リソース及び／若しくはエクスターナルに関連付けられ得る。項目 構造体２７００により表現される項目がリソースの１つと関連している場合、項 目構造体２７００のフィールド“ｒｅｓｏｕｒｃｅ”２７０２が、そのリソース を表現するリソース状態構造体を指定する。逆に、その項目がリソースと関連し ていない場合、フィールド“ｒｅｓｏｕｒｃｅ”２７０２は、そのことを示すべ くＮＵＬＬにされる。項目構造体２７００により表現される項目がエクスターナ ルの１つと関連している場合、項目構造体２７００のフィールド“ｅｘｔｅｒｎ ａｌ”２７０４が、そのエクスターナルを表現するエクスターナル状態構造体を 指定する。逆に、その項目がエクスターナルと関連していない場合、フィールド “ｅｘｔｅｒｎａｌ”２７０４は、そのことを示すべくＮＵＬＬにされる。 項目構造体２７００のフィールド“ｖａｌｕｅ”２７０６は、項目構造体２７ ００によって表現される項目の実際の値を定めるデータを含んでいる。つまり、 フィールド“ｖａｌｕｅ”２７０６に格納されたデータは、メモリ１０４（第１ 図）における、項目構造体２７００（第２７図）によって表現された項目によっ て指定された位置に格納された実際のデータを表現する。項目構造体２７００の フィールド“ｔｙｐｅ ｃ ｏｄｅ”２７１２は、その項目のメモリ位置に格納されたデータの型を指定する 。ここに開示する実施例において支援されているデータの型には、ｌｏｎｇ、ｐ ｏｉｎｔｅｒ、及びｄｏｕｂｌｅがある。最近のＣ言語の実装においては、“ｌ ｏｎｇ”は３２ビットの符号付き整数、“ｐｏｉｎｔｅｒ”はメモリ１０４のよ うなメモリにおけるアドレスを指定する値、また、“ｄｏｕｂｌｅ”は６４ビッ トの浮動小数点である。フィールド“ｖａｌｕｅ”２７０６内には各データの型 に対応するサブフィールドがある。使用されるのはただ１つのサブフィールドで ある。即ちフィールド“ｔｙｐｅ ｃｏｄｅ”２７１２で指定されたデータの型 に対応するサブフィールドのみが使用される。 項目構造体２７００のフィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４は、項 目構造体２７００により表現されたその項目が初期化されているか否か、即ち項 目構造体２７００によって表現される項目が既知の値を有するか否かを示す。項 目構造体２７００のフィールド“ｉｎｖａｌｉｄ ｐｏｉｎｔｅｒ”２７２０は 、項目構造体２７００によって表現される項目が無効ポインタであるか否かを示 す。Ｃ言語においては、ポインタがメモリ１０４（第１図）における有効な位置 を指定している場合、そのポインタは有効である。そうでない場合、そのポイン タは無効である。ＮＵＬＬポインタは、Ｃ言語の多くの実装において０に選択さ れる特定の無効ポインタである。一実施例においては、フィールド“ｉｎｉｔｉ ａｌｉｚｅｄ”２７１４及び“ｉｎｖａｌｉｄ ｐｏｉｎｔｅｒ”２７２０は、 それぞれ１つのビットよりなる。 フィールド“ｆｉｒｓｔ ｉｎ ｂｕｎｃｈ”２７０８、“ｓｉｚｅ ｏｆ ｂｕｎｃｈ”２７１０、“ｈｅａｄ ｉｎ ｂｕｎｃｈ”２７１２、及び“ｋｎ ｏｗｎ ｂｕｎｃｈ ｓｉｚｅ”２７１８は、メモリの集群（bunch）を解析す るのに用いられる。メモリの集群については、 後に詳しく説明する。 ステップ２６０２（第２６図）において、ひとたびこのサブジェクト関数のエ クスターナルが初期化されると、処理はステップ２６０４に進む。ステップ２６ ０４において、サブジェクト関数の各ステートメントが評価される。ステートメ ントの評価は、そのステートメントの実行をエミュレートすることによって行わ れる。ステートメントの評価により、エクスターナル及び／若しくはリソースに 対して施した演算の結果が得られ、エクスターナル及び／若しくはリソースのそ れぞれの状態の変化が生ずる。後に詳しく説明するが、各ステートメントの評価 は論理流れ図２８００（第２８図）に従って個別に行われる。 ひとたびサブジェクト関数の各ステートメントが評価されると、処理はステッ プ２６０４（第２６図）からステップ２６０６に進む。ステップ２６０６におい てはサブジェクト関数の様々なリソースの状態のリーク（leak）がチェックされ る。ステップ２６０６の詳細は論理流れ図２６０６（第４１図）に示されており 、これについては後に説明する。ステップ２６０６から処理はステップ２６０８ に進み、ここでサブジェクト関数の各エクスターナルが更新される。エクスター ナルの更新は、エクスターナルのＤＫ及びＣＰ状態、及びそのエクスターナルに 関連付けられたリソースのＲＳ状態に基づいて、エクスターナルの複合ＤＫ、Ｃ Ｐ、及びＲＳ状態を更新することによって行われる。これらの状態はサブジェク ト関数の現反復的解析（current iterative analysis）から得られる。１つのエ クスターナルの更新は、論理流れ図４２００（第４２図）に示されており、後に 完全に説明する。 ステップ２６０８（第２６図）が終了すると、論理流れ図２６００に従った処 理、即ちサブジェクト関数の反復的解析の１回分が終了する。ステートメントの評価 上述のように、サブジェクト関数の各ステートメントは論理流れ図２８００（ 第２８図）に従って個別に評価される。処理はテストステップ２８０２から開始 されるが、このステップでは実行エンジン８０２（第８図）が、そのステートメ ント、すなわちサブジェクトステートメントの構造体を表すステートメント構造 体のフィールド“ｋｉｎｄ”２１０２（第２１図）を検索することによって、そ のステートメントが式であるか否かを判定する。そのステートメントはサブジェ クトステートメント構造体によって表されるサブジェクトステートメントである 。即ち、その時点で論理流れ図２８００（第２８図）に従って評価されているス テートメントをサブジェクトステートメントと称する。 サブジェクトステートメントが式である場合、すなわちフィールド“ｋｉｎｄ ”２１０２が、サブジェクトステートメントが式であることを示している場合に は、処理はテストステップ２８０２（第２８図）からステップ２８０４に進み、 そこで実行エンジン８０２（第８図）が式、すなわちサブジェクトステートメン トの評価を行う。実行エンジン８０２は、その式に含まれる項目上の関数及び演 算子の実行をエミュレートすることによって式の評価を行う。ステップ２８０４ （第２８図）は論理流れ図２９００（第２９図）に従って実行されるが、これに ついては後に詳述する。 後に詳しく述べるように、論理流れ図２９００に従う処理は、式の評価の結果 得られた項目に対して演算を施し得る。ステップ２８０４の文脈に於いては、式 の項目に対して施される演算は無い。テストステップ２８０２（第２８図）に於 いて、サブジェクトステートメントが式でない場合は、処理はテストステップ２ ８０６に進む。 テストステップ２８０６に於いては、実行エンジン８０２（第８図）がサブジ ェクトステートメント構造体のフィールド“ｋｉｎｄ”２１０ ２とそのサブジェクトステートメントが宣言であることを示すデータとを比較す る。ｄｅｆｉｎｉｎｇ宣言は、項目を生成させるＣ言語に従ったステートメント である。ｄｅｃｌａｒｉｎｇ宣言は、その項目があたかも特定の型であるかのよ うにその項目を取り扱うようＣＰＵ１０２（第１図）に指示するＣ言語に従った ステートメントである。ここで述べたもの以外の場合には、宣言はｄｅｆｉｎｉ ｎｇ宣言となる。 サブジェクトステートメントが宣言である場合、処理はテストステップ２８０ ６（第２８図）からステップ２８０８に進み、ここでその宣言が処理される。こ れについては後に詳しく述べる。逆に、サブジェクトステートメントが宣言でな い場合は、処理はテストステップ２８０６からテストステップ２８１０に進む。 テストステップ２８１０に於いては、実行エンジン８０２（第８図）が、サブ ジェクトステートメント構造体のフィールド“ｋｉｎｄ”２１０２（第２１図） と、サブジェクトステートメントが“ｉｆ”ステートメントであることを示すデ ータとを比較する。そのステートメントが“ｉｆ”ステートメントである場合は 、処理はテストステップ２８１０（第２８図）からステップ２８１２に進み、こ こでそのサブジェクトステートメントが処理される。ステップ２８１２は後に説 明する論理流れ図２８１２（第３５図）により詳細に示されている。逆に、サブ ジェクトステートメントが“ｉｆ”ステートメントでない場合は、処理はテスト ステップ２８１０（第２８図）からテストステップ２８１４に進む。 テストステップ２８１４に於いては、実行エンジン８０２（第８図）が、サブ ジェクトステートメント構造体のフィールド“ｋｉｎｄ”２１０２（第２１図） と、そのサブジェクトステートメントが“ｒｅｔｕｒｎ”ステートメントである ことを示すデータとを比較する。サブジェクトステートメントが“ｒｅｔｕｒｎ ”ステートメントである場合は、処 理はテストステップ２８１４（第２８図）からステップ２８１６に進み、ここで そのステートメントが処理される。ステップ２８１６は後に説明する論理流れ図 ２８１６（第３９図）により詳細に示されている。逆に、そのサブジェクトステ ートメントが“ｒｅｔｕｒｎ”ステートメントでない場合は、処理はテストステ ップ２８１４（第２８図）からテストステップ２８１８に進む。 テストステップ２８１８に於いては、実行エンジン８０２（第８図）が、その サブジェクトステートメントのフィールド“ｋｉｎｄ”２１０２（第２１図）と 、そのサブジェクトステートメントがループ若しくはブロックステートメントで あることを示すデータとを比較する。サブジェクトステートメントがループ若し くはブロックステートメントである場合には、処理はテストステップ２８１８（ 第２８図）からステップ２８２０に進み、そのステートメントが処理される。ス テップ２８２０は後に説明する論理流れ図２８２０（第４０図）により詳細に示 されている。逆に、そのサブジェクトステートメントはループステートメントで もブロックステートメントでもない場合には、処理はテストステップ２８１８（ 第２８図）からテストステップ２８２２に進む。 テストステップ２８２２に於いては、実行エンジン８０２（第８図）が、サブ ジェクトステートメントのフィールド“ｋｉｎｄ”２１０２（第２１図）と、そ のサブジェクトステートメントが“ｇｏｔｏ”ステートメントであることを示す データとを比較する。そのサブジェクトステートメントが“ｇｏｔｏ”ステート メントである場合には、処理はテストステップ２８２２（第２８図）からステッ プ２８２４に進み、そこで実行エンジン８０２（第８図）が、後に詳述するよう に“ｒｅｔｕｒｎ”条件を示すデータを制御レコード内に格納する。この制御レ コードは、後に詳述するようにそのサブジェクト関数の実行のエミュレーション 時 に適切な制御の流れを与えるために用いられる。“ｒｅｔｕｒｎ”条件は、サブ ジェクト関数の反復的解析を終了させる。 サブジェクトステートメントが“ｇｏｔｏ”ステートメントでない場合には、 処理は論理流れ図２８００に従って終了する。 ステップ２８０４、２８０８、２８１２、２８１６、２８２０、または２８２ ４のいずれかが実行されれた後、処理は論理流れ図２８００に従って終了する。 従って、実行エンジン８０２（第８図）によるステートメントの評価は、そのス テートメントが式であるか、宣言であるか、“ｉｆ”ステートメントであるか、 “ｒｅｔｕｒｎ”ステートメントであるか、ブロックステートメントであるか、 ループステートメントであるか、若しくは“ｇｏｔｏ“ステートメントであるか によって、それぞれステップ２８０４（第２８図）、ステップ２８０８、２８１ ２、２８１６、２８２０、２８２４、若しくは２８２８において行われるのであ る。式の評価 上述のように、式は論理流れ図２９００（第２９図）に従って評価されるが、 この場合実行エンジン８０２（第８図）が、動的検査エンジン７０６の一部であ るステートマシン８０４をして、実行エンジン８０２によって指定された演算が ある場合にはその演算をその式の項目に施すようにする。上述のように、ステッ プ２８０４（第２８図）の文脈に於いては、実行エンジン８０２（第８図）はこ のような演算の指定を行わない。ここに開示する本発明の実施例では、式を評価 することで、式であるステートメント若しくは式を含むステートメントの実行に よりその式のオペランドである項目に及ぼす効果を判断している。 論理流れ図２９００（第２９図）に従う処理は、ステップ２９０２から開始さ れるが、ここでは式の評価を行うために、その式に於ける演算 子によって指定された処理が実行される。上述のように、式は、動的検査エンジ ン７０６（第７図）内に於いて式構造体２２００（第２２図）のような式構造体 によって表現される。式構造体２２００のフィールド“ｋｉｎｄ”２２０２はそ の式の演算子の種類を指定し、またフィールド“ｏｐｅｒａｎｄｓ”２２１０は その演算子の演算が施されるオペランドを含む。 このサブジェクト関数の解析は、コンピュータプロセス内に於けるそのサブジ ェクト関数の実行の文脈内で行われるので、このサブジェクト関数のエクスター ナルの初期値は未知である。従って、このサブジェクト関数に於ける式は、既知 の値に評価しなくてもよい。従って、ステップ２９０２（第２９図）での実行エ ンジン８０２（第８図）による式の評価により、式の評価により既知の若しくは 部分的に既知の値が生成される場合には項目が生成され、そうでない場合にはＮ ＵＬＬが生成される。後に詳述するように、項目は、「部分的に既知」の値を有 し得る。例えば、項目が０でない値を有していることは知ることはできるが、項 目の正確な値はまだ知ることができず、この場合その項目の値は「部分的に既知 」であるという。ステップ２９０２は論理流れ図２９０２（第３３ａ図、第３３ ｂ図、及び第３３ｃ図）に詳しく示されており、後に詳細に説明する。 ステップ２９０２（第２９図）から、処理はテストステップ２９０４に進み、 ここで実行エンジン８０２（第８図）が、式の評価によりＮＵＬＬでなく項目が 生成されたか否か、及びステートマシン８０４によりその項目に演算が施される か否かを判定する。その式の評価により項目が生成されない場合、若しくはその 項目に演算が施されない場合には、処理はテストステップ２９０４（第２９図） から後に説明するステップ２９０８に進む。逆に、その式の評価により項目が生 成されその項目に 演算が施される場合には、処理はテストステップ２９０４からステップ２９０６ に進み、そこでステートマシン８０４（第８図）がその項目に演算を施す。 評価された式の項目に演算を施すために、ステートマシン８０４は、その項目 にエクスターナル及びリソースがそれぞれ関連付けられている場合には、その項 目に関連付けられたエクスターナル及びリソースに対して演算を施す。例えば、 項目構造体２７００（第２７図）のフィールド“ｅｘｔｅｒｎａｌ”２７０４が 、項目構造体によって表現された項目に関連付けられたエクスターナルを表現す るエクスターナル状態構造体を指定する。同様に、項目構造体２７００のフィー ルド“ｒｅｓｏｕｒｃｅ“２７０２が、そのアイテムに関連付けられたリソース を表現するリソース状態構造体を指定する。 エクスターナルに施される演算には、例えばエクスターナル状態構造体３００ ０のフィールド“ＤＫ”３００４（第３０図）及び“ＣＰ”３００８の更新があ る。このエクスターナル状態構造体３０００は、そのエクスターナルを表現する エクスターナル状態構造体である。フィールド“ＤＫ”３００４の更新は、その エクスターナルに施される演算に従って、また上述の状態図５００（第５ａ図） に従って行われる。例えば、フィールド“ＤＫ”３００４（第３０図）が状態Ｏ を示しており、そのエクスターナルに演算ｍが施される場合、フィールド“ＤＫ ”３００４は状態Ｑを示すように更新される。フィールド“ＣＰ”３００８の更 新は、状態図４００（第４ａ図）に従って行われる。 リソースに施される演算には、例えば、リソース状態構造体３１００のフィー ルド“ｓｔａｔｅ”３１０２（第３１図）及び“ｍｏｄｉｆｉｅｄ”３１０８の 更新がある。このリソース状態構造体は、そのリソースを表現するリソース状態 構造体である。フィールド“ｓｔａｔｅ”３ １０２は、上述の状態図３００（第３Ａ図）に従って更新される。フィールド“ ｍｏｄｉｆｉｅｄ”３１０８（第３１図）は、現在行を指定するデータをフィー ルド“ｍｏｄｉｆｉｅｄ”３１０８に格納することによって更新され、最後にリ ソースを修正したステートメントを示すようにされる。この現在行とは、コンピ ュータプログラム６１０（第６図）上のそのサブジェクトステートメントが存在 する行を指す。リソースに関連するプログラミングエラーを知らせると共に、最 後にリソースを修正したステートメントをユーザに対して示すことによって、サ ブジェクト関数の開発者がプログラミングエラーを除去する助けとなる。 後に詳しく説明するが、エクスターナル状態構造体３０００のフィールド“Ｄ Ｋ”３００４（第３０図）若しくは“ＣＰ”３００８の更新、またはリソース状 態構造体３１００のフィールド“ｓｔａｔｅ”３１０２（第３１図）の更新によ って、状態図３００、４００、または５００（第３Ａ図、第４図、及び第５図） に基づくエラーが生じた場合には、このエラーはユーザに通知される。式の評価 により生成された項目も、論理流れ図３２００（第３２図）に基づいて状態違反 を調べられる。 テストステップ３２０２（第３２図）においては、ステートマシン８０４（第 ７図）が項目構造体２７００のフィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４ （第２７図）を調べて、項目構造体２７００によって表現された項目が初期化さ れたか否かを判定する。その項目が初期化されていない場合には、処理はテスト ステップ３２０２（第３２図）からステップ３２０４に進み、ここでエラーが報 告される。論理流れ図３２００の各ステップの実行はステップ２９０６（第２９ 図）内においてのみ実行されることから、演算が施されるのは論理流れ図３２０ ０（第３２図）における項目に対してである。従って、その項目が初期化される 場合、演算の適用で示されるように、初期化される前にその項目が使用 され、これがエラーとなる。 その項目が初期化された場合には、処理はテストステップ３２０２からテスト ステップ３２０６に進む。テストステップ３２０６においては、ステートマシン ８０４（第８図）が、項目構造体２７００のフィールド“ｉｎｖａｌｉｄ ｐｏ ｉｎｔｅｒ”２７２０（第２７図）を検査することによりその項目が無効ポイン タであるか否かを判定するとともに、施される演算と、演算ｉ、即ち間接演算と を比較する。その項目が有効ポインタで、演算ｉが施される場合には、処理はス テップ３２０８（第３２図）に進み、そこでエラーが通知される。逆に、その項 目が有効ポインタでなく、若しくは演算ｉ以外の演算が施される場合には、処理 はステップ３２０６からテストステップ３２１０に進む。 テストステップ３２１０において、ステートマシン８０４（第７図）は、その 項目が、テストステップ３２０６に関して上述したのと同様に無効ポインタであ るか否かを判定し、施される演算と演算ｋとを比較する。Ｃ言語の文脈において は、無効ポインタを解放することは、ファイル及び動的に割振られるメモリを管 理するのに使用するデータ構造をライブラリ関数が損なうことになり得るために 、エラーとなる。ＮＵＬＬポインタを解放することは一般的にはエラーではない が、不手際なプログラム作成方法と一般に考えられ、エラーとして通知される。 その項目が無効ポインタであり、演算ｋがその項目に施される場合には、処理は ステップ３２１２に進み、そこでエラーの通知がなされる。逆にその項目が無効 ポインタでないか、若しくは演算ｋ以外の演算が施される場合には、処理は論理 流れ図３２００に従って終了する。また、ステップ３２０４、３２０８、及び３ ２１２の終了後も、処理は論理流れ図３２００に従って終了する。 従って、ステップ２９０６（第２９図）において、項目及びそれに関 連するリソースまたはエクスターナルに演算が施され、何らかのエラーが検出さ れてそれがユーザに通知される。ステップ２９０６から、処理はステップ２９０ ８に進む。また、式の評価により生成された項目が存在しない場合、若しくは上 述のようにその式に対して施される演算が無い場合は、処理はテストステップ２ ９０４から直接ステップ２９０８に進む。ステップ２９０８においては、実行エ ンジン８０２は、式、即ち、サブジェクトステートメントを含んでおり、更に、 項目が生成された場合にはその項目を、生成されなかった場合には数値がＮＵＬ Ｌである項目を含んでいる。詳述すると、実行エンジン８０２はサブジェクトス テートメントを表現する式構造体２２００のフィールド“ｉｔｅｍ”２２０６（ 第２２図）に、その項目を指定するポインタを格納する。従って、後に行われる その式の評価においては、単に、その項目がフィールド“ｉｔｅｍ”２２０６が 指定する部位に戻されるだけとなり、これによって冗長な処理が回避される。ス テップ２９０８（第２９図）の後、処理は論理流れ図２９００に従って終了する 。定数 上述のように、論理流れ図２９０２（第３３Ａ図〜第３３Ｃ図）に詳細に示さ れているステップ２９０２（第２９図）においては、実行エンジン８０２（第８ 図）は、式における演算子によって規定されている通りに式を処理する。実行エ ンジン８０２は、演算の型に応じてその式を処理する。テストステップ３３０１ （第３３Ａ図）においては、論理流れ図２９０２に従って処理が開始されるが、 ここでは実行エンジン８０２（第８図）が、その式が演算子は含んでいないが、 代わりに定数を含んでいるか否かを判定する。式構造体２２００（第２２図）が サブジェクトステートメントの式を表現している場合は、実行エンジン８０２（ 第８図）は、式構造体２２００のフィールド“ｋｉｎｄ”２２０２（第２ ２図）と、式が定数であることを示すデータとを比較することによってこの判定 を行う。定数は、その値がコンピュータプロセスの実行中に変化しない項目であ る。例えば、式“１０”は、整数であり、その値が常に１０である定数である。 その式が定数でない場合には、処理は後に述べるテストステップ３３０３（第 ３３Ａ図）に進む。逆に、式が定数である場合には、処理はテストステップ３３ ０１からステップ３３０２の進む。ステップ３３０２においては、実行エンジン ８０２（第８図）が定数を表現する項目構造体を生成し、その項目構造体を、そ の定数の値を有するように初期化する。ステップ３３０２の終了後、処理は論理 流れ図２９０２及びステップ２９０２（第２９図）に従って終了する。変数 上述のように、その式が定数でない場合には、処理はテストステップ３３０１ （第３３Ａ図）からテストステップ３３０３に進む。テストステップ３３０３に おいては、実行エンジン８０２（第８図）が、その式を表現する式構造体のフィ ールド“ｋｉｎｄ”２２０２（第２２図）と、その式が変数であることを示すデ ータとを比較することによって、その式が変数であるか否かを判定する。変数で ある式は、その変数の項目の現項目値に評価される。例えば、サブジェクト関数 の以前に処理されたステートメントが、識別子が“ｉ”、即ち型が“ｉｎｔ”、 即ち整数である変数“ｉ”である変数を宣言する場合には、式“ｉ”は、変数“ ｉ”の項目の現項目値に評価される。式が変数でない場合には、処理は後に説明 するテストステップ３３０５（第３３Ａ図）に進む。逆に、その式が変数である 場合には、処理はテストステップ３３０３からステップ３３０４に進む。 ステップ３３０４においては、実行エンジン８０２（第８図）が変数 ｉの項目を検索する。式構造体２３００（第２３図）がその式を表現する場合、 即ち変数を表現する場合には、（ｉ）フィールド“ｎｕｍ ｏｐｅｒａｎｄｓ” ２３０８が、１つのオペランドを指定する値１を有し、（ｉｉ）フィールド“ｏ ｐｅｒａｎｄｓ”２３１０が宣言構造体２３１０を指定する１つのポインタの配 列となる。宣言構造体２３１６のフィールド“ｉｔｅｍ”２３２４は、式２３０ ０の値として検索される。宣言構造体２３１６に関連付けられた項目が存在しな い場合には、フィールド“ｉｔｅｍ”２３２４はＮＵＬＬとなる。従って、存在 する項目構造体またはＮＵＬＬの何れかが、ステップ３３０４（第３３Ａ図）に おいて取り出されるのである。ステップ３３０４の終了後、処理は論理流れ図２ ９０２即ちステップ２９０２（第２９図）に従って終了する。２項演算子 上述のように、その式が宣言でない場合には、処理はテストステップ３３０３ （第３３Ａ図）からテストステップ３３０５に進む。テストステップ３３０５に おいて、実行エンジン８０２（第８図）は、その式を表現する式構造体のフィー ルド“ｋｉｎｄ”２２０２（第２２図）と２項演算子を示すデータとを比較する ことによって、その式の演算子が２項演算子であるか否かを判定する。２項演算 子は２つのオペランドに対して演算を施す演算子であって、関係演算子ではない 演算子である。例えば、式“ａ＋ｂ”には、加算を指定する２項演算子“＋”が 含まれている。関係演算子については後に説明する。 論理流れ図２９０２（第３３Ａ図）に従って処理される式の演算子が２項演算 子でない場合には、処理はテストステップ３３０５からテストステップ３３０９ に進む。逆に、式の演算子が２項演算子である場合には、処理はテストステップ ３３０５からステップ３３０６に進む。ステップ３３０６においては、左側のオ ペランド、即ち“ｌｈｓ”が論理流 れ図２９００（第２９図）に従って式として評価される。２つのオペランドを有 し、式構造体２２００（第２２図）によって表現される式のｌｈｓは、フィール ド“ｏｐｅｒａｎｄｓ”２２１０の第１の要素である式構造体よって表現される 。このｌｈｓは、論理流れ図２９００（第２９図）に従って評価されるとともに 、演算Ｃが施される。論理流れ図２９００に従って演算を施すことについては、 前に説明した。従って、論理流れ図２９００に従った式の評価は反復的に行われ る。つまり、論理流れ図２９００に従った式の評価により、論理流れ図２９００ に従ったその式の部分式（subexpression）の評価も行われることになり得るの である。このような再帰的プログラミングは周知の技術である。 ２項演算子は、左側のオペランドと共に、右側のオペランド、即ち“ｒｈｓ” を有する。例えば、式“（ａ＋ｂ）＊ｃ”は、ｌｈｓ“（ａ＋ｂ）”と、ｒｈｓ “ｃ”とを有する。というのはこの式の中で最も優先順位の高いものは、演算子 “＊”、即ち乗算演算子だからである。２つのオペランドを有し、式構造体２２ ００（第２２図）によって表現される式のｒｈｓは、フィールド“ｏｐｅｒａｎ ｄｓ”２２１０の第２要素の式構造体によって表現される。ステップ３３０６（ 第３３Ａ図）において式のｌｈｓが評価された後、処理はステップ３３０７に進 み、ここで実行エンジン８０２（第８図）が、論理流れ図２９００（第２９図） に従ってこの式のｒｈｓの評価を行うとともに、演算ｃを施す。演算ｃは、式の ｌｈｓ及びｒｈｓの双方に施されるが、これはそれぞれが計算において使用され るからである。このような計算において、式のｌｈｓ若しくはｒｈｓの何れかを 不適切に使用している場合は、上述のように演算を施すことによってエラーメッ セージが生成される。 ステップ３３０７（第３３Ａ図）から、処理はステップ３３０８に進み、ここ でその式の２項演算子を用いて式の評価が行われる。この式の ｌｈｓ及びｒｈｓのデータの型は演算子によって呼び出される演算の型に影響す る。Ｃ言語において、特定の演算子が特定の型のオペランドに対して実行する演 算の型は、Ｃスタンダードのセクション６．３他に記載されており、周知である 。 式の演算子は、Ｃスタンダードに記載された所定の演算子の適用方法に従って 式のオペランドに適用される。例えば、演算子が算術加算演算子（即ち“＋”） である場合には、演算子を２つのオペランドに適用した結果、２つのオペランド の算術和が得られる。第２の例として、演算子が、一方の値が他方より大きいこ とを表す関係演算子（即ち、“＞”）である場合には、この演算子は２つのオペ ランド、即ちｌｈｓとｒｈｓとに適用することにより、ｌｈｓの値がｒｈｓの値 より大きい場合にはブール値“ｔｒｕｅ（真）”が得られ、逆の場合にはブール 値“ｆａｌｓｅ（偽）”が得られる。 コンピュータプログラム６１０におけるリソースの不適切な使用を検出するリ ソースチェッカー６０２（第６図）のために、実行エンジン８０２（第８図）に よりＣ言語の全ての演算子が適切に適用される必要は必ずしもない。式が実行エ ンジン８０２（第８図）によって適用され得ない演算子を含む場合、この式はＮ ＵＬＬに評価され、その式の評価により値が未知の項目が生成されることが示さ れる。しかし、実行エンジン８０２が、できる限り多くのＣ言語の演算子を適用 して、リソースチェッカー６０２によって検出されたリソースの不適切な使用を 正しく改善し得るのは好ましいことである。 ステップ３３０８（第３３Ａ図）の後、処理は論理流れ図２９０２、即ちステ ップ２９０２（第２９図）に従って終了する。関係演算子 上述のように、式の演算子が２項演算子でない場合には、処理はテス トステップ３３０５（第３３Ａ図）からテストステップ３３０９に進む。テスト ステップ３３０９においては、実行エンジン８０２（第８図）が、その式の演算 子が関係演算子であるか否かを判定する。関係演算子は２つのオペランド、即ち ｌｈｓ及びｒｈｓに対して演算を行い、演算結果として２つのオペランドの値を 比較したブール値に対応する数値を有する項目を生成する演算子である。ブール 値は、“ｔｒｕｅ”若しくは“ｆａｌｓｅ”の何れかである。関係演算子の具体 例には、“＝＝”（等しい）、“＞＝”（大きいか若しくは等しい）、“＜＝” （小さいか若しくは等しい）、及び“！＝”（等しくない）がある。 この式の演算子が関係演算子でない場合は、処理はテストステップ３３０９（ 第３３Ａ図）から、後に説明するテストステップ３３１３に進む。逆に式の演算 子が関係演算子である場合は、処理はテストステップ３３０９からステップ３３ １０に進む。ステップ３３１０においては、実行エンジン８０２（第８図）が、 論理流れ図２９００（第２９図）に従って式のｌｈｓを式として評価するととも に、演算ｐを適用する。ステップ３３１０（第３３Ａ図）から、処理はステップ ３３１１へ進み、ここで実行エンジン８０２（第８図）が論理流れ図２９００（ 第２９図）に従って、式のｒｈｓの評価を行うとともに、演算ｐを適用する。演 算ｐは式のｌｈｓ及びｒｈｓの双方に適用されるが、これはそれぞれが比較のた めに使用されるからである。このような比較処理において、式のｌｈｓ若しくは ｒｈｓの何れかが不適切に使用されている場合には、上述のように演算が適用さ れることによりエラーメッセージが生成される。 処理はステップ３３１１（第３３Ａ図）からステップ３３１２に進み、ここで 式の関係演算子が用いられて式の評価が行われる。ステップ３３１２は、前に説 明したステップ３３０２に類似している。ステップ３３１２の終了後、処理は論 理流れ図２９０２に従って、即ちステップ２９ ０２（第２９図）に従って終了する。単項演算子 上述のように、この式の演算子が関係演算子でない場合には、処理はテストス テップ３３０９（第３３Ａ図）からテストステップ３３１３に進む。テストステ ップ３３１３においては、実行エンジン８０２（第８図）が、式の演算子が単項 演算子であるか否かを、その式を表現する式構造体のフィールド“ｋｉｎｄ”２ ２０２（第２２図）と、単項演算子を示すデータとを比較することによって判定 する。単項演算子は、ただ１つのオペランドを有する演算を特定する演算子であ る。例えば、式“−ａ”は、ただ１つのオペランド“ａ”と、オペランド“ａ” に対して数値を負にする演算を特定する単項演算子“−”とを有する。式が１つ のオペランドを有し、かつ式構造体２２００によって表現されている場合には、 その式のただ１つのオペランドが、フィールド“ｏｐｅｒａｎｄｓ”２２１０の 第１の要素である式構造体によって表現される。 式の演算子が単項演算子でない場合には、処理はテストステップ３３１３（第 ３３Ａ図）から、後に説明するテストステップ３３１３（第３３Ｂ図）に進む。 逆に、式の演算子が単項演算子である場合には、処理はテストステップ３３１３ （第３３Ａ図）からステップ３３１４に進む。ステップ３３１４においては、実 行エンジン８０２（第８図）が、論理流れ図２９００（第２９図）に従って式の オペランドを式として評価するとともに、演算ｃを適用する。演算ｃは、式のオ ペランドに適用されるが、これはこのオペランドが計算において使用されるから である。このような計算において式のオペランドが不適切に使用されている場合 には、上述のように、演算を適用することによりエラーメッセージが生成される 。 処理はステップ３３１４（第３３Ａ図）からステップ３３１５に進み、 ここでは式の単項演算子が式の評価のために用いられる。ステップ３３１５は上 述のステップ３３０８に類似している。ステップ３３１５の終了後、処理は論理 流れ図２９０２、即ちステップ２９０２（第２９図）に従って終了する。特定の演算子による処理 上述のように、式の演算子が単項演算子でない場合には、処理はテストステッ プ３３１３（第３３Ａ図）からテストステップ３３１７（第３３Ｂ図）に進む。 更に上述したように、論理流れ図２９０２における上述のステップでは、式の演 算子の型に従って式の処理が行われる。テストステップ３１７及びそれに続くス テップにおいて、式の演算子の型がテストステップ３３０１（第３３Ａ図）、３ ３０３、３３０５、３３０９及び３３１３で判定される演算子の型の中に入って いない場合に、実行エンジン８０２（第８図）が、式の特定の演算子に従って式 の処理を行う。インクリメント演算子またはデクリメント演算子 ステップ３３１７（第３３Ｂ図）においては、実行エンジン８０２（第８図） が、式の演算子とインクリメント演算子及びデクリメント演算子とを比較する。 つまり、式構造体２２００（第２２図）がその式を表現している場合、実行エン ジン８０２は、フィールド“ｋｉｎｄ”２２０２（第２２図）と、インクリメン ト演算子若しくはデクリメント演算子を指定するデータとを比較する。インクリ メント演算子若しくはデクリメント演算子は、１つのオペランドに対してそのオ ペランドを１づつ増減させる演算を施す。その式の演算子がインクリメント演算 子でもデクリメント演算子でもない場合には、処理は、後に説明するテストステ ップ３３２０（第３３Ｂ図）に進む。逆に、式の演算子がインクリメント演算子 またはデクリメント演算子である場合には、処理はテストステッ プ３３１７からステップ３３１８に進む。 ステップ３３１８においては、実行エンジン８０２（第８図）が、論理流れ図 ２９００（第２９図）に従ってそのオペランドを評価し、演算ｃを適用する。演 算ｃを適用するのは、このオペランドが計算において使用されるからである。上 述のように、演算ｃをそのオペランドに対して適用することにより生じた何らか のエラーは検出され通知される。 処理はステップ３３１８（第３３Ｂ図）からステップ３３１９に進み、ここで は式のインクリメント演算子またはデクリメント演算子が用いられて、その式の 評価が行われる。ステップ３３１９は、上述のステップ３３０８（第３３Ａ図） に類似している。ステップ３３１９（第３３Ｂ図）の終了後、処理は論理流れ図 ２９０２に従って、即ちステップ２９０２（第２９図）に従って終了する。“Ｎｏｔ”演算子 上述のように、式の演算子がインクリメント演算子でもデクリメント演算子で もない場合には、処理はテストステップ３３１７（第３３Ｂ図）からテストステ ップ３３２０に進む。テストステップ３３２０においては、実行エンジン８０２ （第８図）が、その式を表す式構造体のフィールド“ｋｉｎｄ”２２０２（第２ ２図）と“Ｎｏｔ”演算子を指定するデータとを比較することによって、Ｃ言語 の“Ｎｏｔ”演算子と式の演算子とを比較する。“Ｎｏｔ”演算子は、ただ１つ のオペランドに対して演算を施し、そのオペランド自体をブール値項目として取 り扱って、オペランドの論理的否定のブール値に対応する値を有する項目を生成 する。ブール値項目は、真若しくは偽の何れかのブール値に対応する値を有する 項目である。 その式の演算子が“Ｎｏｔ”演算子でない場合は、処理はテストステップ３３ ２０（第３３Ｂ図）からテストステップ３３２３に進む。逆に 式の演算子が“Ｎｏｔ”演算子である場合は、処理はテストステップ３３２０か ら３３２１に進む。ステップ３３２１においては、実行エンジン８０２（第８図 ）が、論理流れ図２９００（第２９図）に従ってオペランドの評価を行うととも に、演算ｐを施す。演算ｐを施すのは、このオペランドは真理値計算を行うのに 使用されるからである。上述のように、オペランドに演算ｐを適用することによ って生じたエラーは全て通知される。 処理はステップ３３２１（第３３Ｂ図）からステップ３３２２に進み、ここで “Ｎｏｔ”演算子がその式を評価するのに用いられる。ステップ３３２２は、前 に説明したステップ３３０８（第３３Ａ図）に類似している。ステップ３３２２ （第３３Ｂ図）の終了後、処理は論理流れ図２９０２に従って、即ちステップ２ ９０２（第２９図）に従って終了する。“Ａｎｄ”演算子及び“Ｏｒ”演算子 上述のように、式の演算子が“ＮＯｔ”演算子でない場合には、処理はテスト ステップ３３２０（第３３Ｂ図）からテストステップ３３２３に進む。テストス テップ３３２３において、実行エンジン８０２（第８図）は、その式を表現する 式構造体のフィールド“ｋｉｎｄ”２２０２（第２２図）と、“Ａｎｄ”演算子 及び“Ｏｒ”演算子を指定するデータとを比較することによって、Ｃ言語の“Ａ ｎｄ”演算子及び“Ｏｒ”演算子と式の演算子との比較を行う。この“Ａｎｄ” 演算子及び“Ｏｒ”演算子は２つのオペランド、即ちｌｈｓ及びｒｈｓに演算を 施し、そのオペランドをブール値項目として取り扱ってそのブール値の論理積及 び論理和のブール値を有する項目を生成する。 式の演算子が“Ａｎｄ”演算子でも“Ｏｒ”演算子でもない場合には、処理は テストステップ３３２３（第３３Ｂ図）からテストステップ３３２７に進む。逆 に、式の演算子が“Ａｎｄ”演算子または“Ｏｒ”演算 子である場合には、処理はテストステップ３３２３からステップ３３２４に進む 。 ステップ３３２４においては、実行エンジン８０２（第８図）が論理流れ図２ ９００（第２９図）に従って、その式のｌｈｓをその式そのものとして評価する とともに、演算ｐを施す。ステップ３３２４（第３３Ｂ図）から、処理はステッ プ３３２５に進み、ここでは実行エンジン８０２（第８図）が、論理流れ図２９ ００（第２９図）に従って式のｒｈｓの評価を行うと共に、演算ｐを適用する。 演算ｐは式のｌｈｓ及びｒｈｓの双方に施されるが、これはそれぞれが真理値計 算に用いられるからである。このような真理値計算において式のｌｈｓまたはｒ ｈｓの何れかを不適切に用いた場合には、上述のように演算ｐを適用することに よってエラーメッセージが生成される。 処理はステップ３３２５（第３３Ｂ図）からステップ３３２６に進み、ここで 式の“Ａｎｄ”演算子または“Ｏｒ”演算子が用いられて、式の評価が行われる 。ステップ３３２６は、前述のステップ３３０８（第３３Ａ図）に類似している 。ステップ３３２６（第３３Ｂ図）の終了後、処理は論理流れ図２９０２に従っ て、即ちステップ２９０２（第２９図）に従って終了する。複合演算子 上述のように、式の演算子が“Ａｎｄ”演算子でも“Ｏｒ”演算子でもない場 合には、処理はテストステップ３３２３（第３３Ｂ図）からテストステップ３３ ２７に進む。テストステップ３３２７において、実行エンジン８０２（第８図） は、その式の演算子が複合演算子（compound operator）であるか否かを、その 式を表現する式構造体のフィールド“ｋｉｎｄ”２２０２（第２２図）と、複合 演算子を指定するデータとを比較することによって判定する。Ｃ言語においては 、複合演算子、即ちカ ンマ（“，”）は、２つのオペランド、即ち式のｌｈｓ及びｒｈｓに対して演算 を施し、演算結果としてｒｈｓを評価した値を有する項目を生成する。つまり、 ２つのオペランドは個別に評価され、式のｒｈｓを評価した値が式の値になるの である。 式の演算子が複合演算子でない場合には、処理はテストステップ３３２７（第 ３３Ｂ図）からテストステップ３３３０に進む。逆に、式の演算子が複合演算子 である場合には、処理はテストステップ３３２７からステップ３３２８に進む。 ステップ３３２８においては、実行エンジン８０２（第８図）が論理流れ図２ ９００（第２９図）に従って式のｌｈｓをその式として評価し、また演算の適用 は行わない。ステップ３３２８（第３３Ｂ図）から処理はステップ３３２９に進 み、ここでは実行エンジン８０２（第８図）が論理流れ図２９００（第２９図） に従って式のｒｈｓを評価する。論理流れ図２９００に従って、複合演算子を含 む式を評価する場合に施される演算は、ステップ３３２９（第３３Ｂ図）におい てｒｈｓを評価するときにｒｈｓに施される演算と類似したものである。式のｒ ｈｓの評価によって生成される項目は、その式そのものの項目として戻される。 ステップ３３２９（第３３Ｂ図）の終了後、処理は論理流れ図２９０２に従って 、即ちステップ２９０２（第２９図）に従って終了する。間接演算子 上述のように、式の演算子が複合演算子でない場合には、処理はテストステッ プ３３２７（第３３Ｂ図）からテストステップ３３３０に進む。テストステップ ３３３０においては、実行エンジン８０２（第８図）がその式の演算子が間接演 算子（indirection operator）であるか否かを、その式を表す式構造体のフィー ルド“ｋｉｎｄ”２２０２（第２２図）と間接演算子を指定するデータとを比較 することによって判定する。Ｃ 言語においては、間接演算子（即ち“＊”）は１つのオペランドに対して演算を 施し、演算結果としてメモリ、即ちメモリ１０４（第１図）内のそのオペランド によって指定されたアドレスに格納された値を有する項目を生成する。例えば、 式“＊ａ”は、メモリ内のアドレス“ａ”に格納された値を有する項目に対して 評価を行う。間接演算子は、配列の要素を参照するためにも使用され得る。例え ば、宣言“ｉｎｔ ａｒｒａｙ[１０]”によって規定された配列の第２要素は、 “ａｒｒａｙ[１]”または“＊（ａｒｒａｙ＋１）”の何れかによって特定され 得る。後者の式はその配列の要素のサイズのアレイの始まる点を０としたときの 相対位置（オフセット）１に格納された値、即ち配列の第２要素の値を参照する ものである。 その式の演算子が間接演算子でない場合には、処理はテストステップ３３３０ （第３３Ｂ図）からテストステップ３３３５に進む。逆に、その式の演算子が間 接演算子である場合には、処理はテストステップ３３３０からテストステップ３ ３３１に進む。 テストステップ３３３１においては、実行エンジン８０２（第８図）がそのオ ペランドが配列であるか否かを判定する。式構造体２２２０（第２２図）がその オペランドを表現している場合には、フィールド“ｔｙｐｅ”２２０４（第２２ 図）がそのオペランドの型を指定する型構造体を指定する。例えば、型構造体１ ６１２（第１７図）が式構造体２２２０のフィールド“ｔｙｐｅ”２２０４（第 ２２図）によって指定されている場合には、実行エンジン８０２（第８図）がそ のオペランドが配列であるか否かを、フィールド“ｋｉｎｄ”１７０２（第１７ 図）と配列を指定するデータとを比較することによって判定する。 そのオペランドが配列である場合には、処理はテストステップ３３３１（第３ ３Ｂ図）からステップ３３３２に進み、ここで実行エンジン８ ０２（第８図）が、論理流れ図２９００（第２９図）に従って、そのオペランド をその式として評価し、かつ演算は適用しないが、その演算子を、配列の間接ア ドレス指定手段として、即ち上述の“＊（ａｒｒａｙ＋１）”の型式の配列の１ つの要素の参照要素として取り扱う。逆に、オペランドが配列でない場合には、 処理はテストステップ３３３１（第３３Ｂ図）からステップ３３３３に進み、こ こでは実行エンジン８０２（第８図）が、論理流れ図２９００（第２９図）に従 ってその式のオペランドを評価するとともに、演算ｉを適用し、かつその演算子 を間接アドレスを指定するポインタ、即ち上述の式“＊ａ”のためのものとして 取り扱う。 処理はステップ３３３２（第３３Ｂ図）またはステップ３３３３の何れかから 、ステップ３３３４に進み、ここでは実行エンジン８０２（第８図）が、そのオ ペランドをデリファレンスする。オペランドのデリファレンスにおいて、その式 の評価により、オペランドが指定する項目が生成される。オペランドが項目を指 定していない場合には、式はＮＵＬＬに評価される。ステップ３３３４（第３３ Ｂ図）の終了後、論理流れ図２９０２に従って、即ちステップ２９０２（第２９ 図）に従って処理は終了する。コンポーネント参照演算子 上述のように、式の演算子が間接演算子でない場合には、処理はテストステッ プ３３３０（第３３Ｂ図）からテストステップ３３３５に進む。テストステップ ３３３５においては、実行エンジン８０２（第８図）が、その式の演算子がコン ポーネント参照演算子であるか否かを、その式を表現する式構造体のフィールド “ｋｉｎｄ”２２０２（第２２図）と、コンポーネント参照演算子を指定するデ ータとを比較することによって判定する。Ｃ言語においては、コンポーネント参 照演算子（即ち、“．” または“−＞”）は、２つのオペランド、即ち式のｌｈｓ及びｒｈｓに対して演 算を施し、演算結果としてｒｈｓによって特定されたｌｈｓのフィールド項目を 生成する。例えば、宣言“ｓｔｒｕｃｔ｛ｉｎｔ ａ；ｃｈａｒ ＊ｂ｝ｃ，＊ ｄ”が宣言しているのは、項目“ｃ”及び第２項目に対するポインタ“ｄ”であ って、それぞれが、データの型“ｉｎｔ”、即ち整数の第１フィールド項目“ａ ”及びデータの型が“ｃｈａｒ”、即ち文字であるデータを指定する第２フィー ルド項目“ｂ”を有することを表している。式“ｃ．ａ”は、項目“ｃ”の整数 フィールド項目に評価される。同様に、式“ｄ−＞ａ”は、ポインタ“ｄ”が指 定する項目の整数フィールド項目に評価される。 式の演算子がコンポーネント参照演算子でない場合には、処理はテストステッ プ３３３５（第３３Ｂ図）からテストステップ３３３８（第３３Ｃ図）に進む。 逆に式の演算子がコンポーネント参照演算子である場合には、処理はテストステ ップ３３３５（第３３Ｂ図）からステップ３３３６に進む。 ステップ３３３６においては、実行エンジン８０２（第８図）が論理流れ図２ ９００（第２９図）に従って式のｌｈｓを評価し、また演算は施されない。ステ ップ３３３６（第３３Ｂ図）から、処理はステップ３３３７に進み、ここで実行 エンジン８０２（第８図）が、式のｒｈｓによって指定されるフィールドを検索 する。ステップ３３３７の終了後、処理は論理流れ図２９０２に従って、即ちス テップ２９０２（第２９図）に従って終了する。配列参照演算子 上述のように、式の演算子がコンポーネント演算子でない場合には、処理はテ ストステップ３３３５（第３３Ｂ図）からテストステップ３３３８（第３３Ｃ図 ）に進む。テストステップ３３３８においては、実行 エンジン８０２（第８図）が式の演算子が配列参照演算子であるか否かを、その 式を表現する式構造体のフィールド“ｋｉｎｄ”２２０２（第２２図）と、配列 参照演算子を指定するデータとの比較を行うことによって判定する。Ｃ言語にお いては、配列参照演算子（即ち、“ [] ”）は２つのオペランド、即ちその式の ｌｈｓ及びｒｈｓに対して演算を施し、演算結果として、ｒｈｓにより特定され るｌｈｓの配列の要素を生成する。例えば、宣言“ｉｎｔ ａｒｒａｙ［１０］ ”が宣言するのは１０個の整数の配列である。式“ａｒｒａｙ［ｂ］”は、配列 “ａｒｒａｙ”の、項目“ｂ”によって指定される位置に存在する整数の要素に 評価される。項目“ｂ”、即ちｒｈｓは指標（index）と称されることもある。 Ｃ言語においては、配列参照演算子は、非配列ポインタからのオフセットを参 照するためにも使用されうる。例えば、“ｄａｔｕｍ”が型が“ｉｎｔ”である 変数である場合、式“ｄａｔｕｍ［２］”は、メモリ１０４（第１図）の、変数 “ｄａｔｕｍ”を表現する項目から２メモリ位置だけオフセットした位置に格納 されたデータに評価される。２メモリ位置は、変数“ｄａｔｕｍ”の型、即ちデ ータの型“ｉｎｔ”の変数２つ分の長さに等しい。上述のように、Ｃ言語の文脈 においては、“ａｒｒａｙ［ｉ］”及び“＊（ａｒｒａｙ＋ｉ）”は、等価な式 である（Ｃスタンダードのセクション６．３、２．１参照）。 その式の演算子が配列参照演算子でない場合は、処理はテストステップ３３３ ８（第３３Ｃ図）からテストステップ３３４４に進む。逆に、この式の演算子が 配列参照演算子である場合には、処理はテストステップ３３３８からステップ３ ３３９に進む。 ステップ３３３９において、実行エンジン（第８図）は、論理流れ図２９００ （第２９図）に従ってその式の指標を評価し、また演算ｃを施 す。演算ｃを施すのは、この指標は計算に使用されるからである。ステップ３３ ３９（第３３Ｃ図）から、処理はテストステップ３３４０に進み、ここで実行エ ンジン８０２（第８図）が、ｌｈｓが配列であるか否かを、テストステップ３３ ３１（第３３Ｂ図）に関連して前に説明した方法で判定する。ｌｈｓが配列であ る場合には、処理はテストステップ３３４０（第３３Ｃ図）からステップ３３４ １に進み、ここで実行エンジン８０２（第８図）が、論理流れ図２９００（第２ 図）に従ってその式のｒｈｓを指標として評価する。このとき演算は施されない 。逆に、ｌｈｓが配列でない場合には、処理はテストステップ３３４０（第３３ Ｃ図）からステップ３３４２に進み、ここで実行エンジン８０２（第８図）が論 理流れ図２９００（第２９図）に従ってその式のｒｈｓをポインタとして評価し 、かつ演算ｉを施す。 処理はステップ３３４１（第３３Ｃ図）若しくはステップ３３４２の何れかか ら、ステップ３３４３に進み、ここで実行エンジン８０２（第８図）が、ｌｈｓ によって特定された配列の、ｒｈｓによって指定された要素を検索する。ステッ プ３３４３（第３３Ｃ図）の終了後、処理は論理流れ図２９０２に従って、即ち ステップ２９０２（第２９図）に従って終了する。アドレス演算子 上述のように、その式の演算子が配列演算子でない場合には、処理はテストス テップ３３３８（第３３Ｃ図）からテストステップ３３４４に進む。テストステ ップ３３４４においては、実行エンジン８０２（第８図）が、その式の演算子が アドレス演算子であるか否かを、その式を表現する式構造体のフィールド“ｋｉ ｎｄ”２２０２と、アドレス演算子を指定するデータとを比較することによって 判定する。Ｃ言語においては、アドレス演算子（即ち“＆”）は、１つのオペラ ンドに対して演算 を施し、演算結果としてオペランドのアドレスがその値である項目を生成する。 例えば、式“＆ａ”は、メモリ、即ちメモリ１０４内の、項目“ａ”が格納され ているアドレスをその値とする項目に評価される。 その式の演算子がアドレス演算子でない場合には、処理はテストステップ３３ ４４（第３３Ｃ図）からテストステップ３３４７に進む。逆に、その式の演算子 がアドレス演算子である場合には、処理はテストステップ３３４４からステップ ３３４５に進む。 ステップ３３４５においては、実行エンジン８０２（第８図）が、論理流れ図 ２９００（第２９図）に従ってオペランドの評価を行い、このとき他の演算は施 されない。ステップ３３４５（第３３Ｃ図）から、処理はテストステップ３３４ ６に進み、ここでこのアドレス演算子はその式を評価するのに使用される。つま り、オペランドのアドレスが決定されるのである。ステップ３３４６は、前に説 明したステップ３３０８（第３３Ａ図）に類似している。ステップ３３４６（第 ３３Ｃ図）が終了した後、処理は論理流れ図２９０２に従って、即ちステップ２ ９０２（第２９図）に従って終了する。関数の呼出し 上述のように、式の演算子がアドレス演算子でない場合には、処理はテストス テップ３３４４（第３３Ｃ図）からテストステップ３３４７に進む。テストステ ップ３３４７においては、実行エンジン８０２（第８図）が、その式の演算子が 関数の呼出しであるか否かを、その式を表現する式構造体のフィールド“ｋｉｎ ｄ”２２０２（第２２図）と、関数の呼出しを指定するデータとを比較すること によって判定する。Ｃ言語においては、関数演算子（即ち“ () ”）は、関数の 呼出しを意味する。関数の呼出しは、その関数の戻り値項目（returned item） に評価される。例えば、式“ａｂｃ () ”は、識別子が“ａｂｃ”である関数の 実行の 呼出しを行う。同様に、式“ｘｙｚ（ｄ，ｅ，ｆ）”は、その識別子が“ｘｙｚ ”である、パラメータとして項目ｄ，ｅ，及びｆが与えられている関数を呼び出 す。 式の演算子が関数の呼出しでない場合には、処理はテストステップ３３４７（ 第３３Ｃ図）からテストステップ３３５３に進む。逆に、式の演算子が関数の呼 出しである場合には、処理はテストステップ３３４７からループステップ３３４ ８に進む。 ループステップ３３４８、ステップ３３４９、及びＮＥＸＴステップ３３５０ は、各パラメータの評価が行われるループを形成する。ステップ３３４９におい て、実行エンジン８０２（第８図）は、論理流れ図２９００（第２９図）に従っ てパラメータの評価を行い、また演算は施さない。式構造体２２００（第２２図 ）がその式を表現している場合、即ち関数の呼出しを表現している場合には、（ ｉ）フィールド“ｎｕｍｏｐｅｒａｎｄｓ”２２０８が呼び出された関数のパラ メータの数をオペランドの数として特定し、（ｉｉ）フィールド“ｏｐｅｒａｎ ｄｓ”２２１０は式構造体の配列であり、この式構造体の各要素は呼び出された 関数のパラメータを表現する式構造体である。各パラメータの評価は、フィール ド“ｏｐｅｒａｎｄｓ”２２１０の各要素を評価することによって行われる。呼 び出された関数のパラメータを表現する項目の配列は、ループステップ３３４８ 、ステップ３３４９、及びＮＥＸＴステップ３３５０によって形成されたループ において構成され、後に（第４６図に関連して）詳しく説明するように、ステッ プ３３５２において呼び出された関数の実行をエミュレートするのに用いられる 。 ひとたび呼出される関数の各パラメータが評価されると、処理はループステッ プ３３４８（第３３Ｃ図）からステップ３３５１に進む。ステップ３３５１にお いては、実行エンジン８０２（第８図）が、呼び出さ れる関数のエクスターナルにおける実行の効果を表現する関数モデル構造体を抽 出する。関数モデル構造体は、第１１図〜第１３図に関連して以前に説明してあ る。ステップ３３５１（第３３Ｃ図）から、処理はステップ３３５２に進み、こ こで実行エンジン８０２（第８図）が、呼び出される関数の実行のエミュレート については後に詳しく説明する。ここで簡単に説明すると呼び出される関数のエ ミュレートは、上述の関数モデル（３）、（４）、及び（５）から形成される関 数モデル構造体のような、関数モデル構造体において特定された演算を適用する ことによって行われる。この呼び出された関数に対応する関数モデル構造体は、 呼び出される関数のエクスターナルにおける実行の効果を表現する演算を特定す る。ステップ３３５２（第３３Ｃ図）の終了後、処理は、論理流れ図２９０２に 従って、即ちステップ２９０２（第２９図）に従って終了する。代入 上述のように、その式の演算子が関数の呼出しでない場合には、処理はテスト ステップ３３４７（第３３Ｃ図）からテストステップ３３５３に進む。テストス テップ３３５３においては、実行エンジン８０２（第８図）が、その関数の演算 子が代入演算子であるか否かをその式を表現する式構造体のフィールド“ｋｉｎ ｄ”２２０２（第２２図）と、代入演算子を指定するデータとを比較することに よって判定する。Ｃ言語においては、代入演算子（即ち“＝”）が、２つのオペ ランド、即ちｌｈｓ及びｒｈｓに対して演算を施し、ｒｈｓの値をｌｈｓに移す 。代入は、移された値を有する項目に評価される。例えば、式“ａ＝ｂ”は、項 目“ｂ”の値を項目“ａ”に移し、項目“ａ”の新たな値を有する項目に評価さ れる。 式の演算子が代入演算子でない場合には、処理は論理流れ図２９０２ （第３３Ａ図〜第３３Ｃ図）に従って、即ちステップ２９０２（第２９図）に従 って終了し、論理流れ図２９０２に従って処理された式はＮＵＬＬ値に評価され る。ＮＵＬＬ値は、有効値を持たない状態を示すために用いられる。 実行エンジン８０２（第８図）が、コンピュータプロセス内におけるサブジェ クト関数の実行の文脈を欠いた式を適切に評価することができない場合には、式 はＮＵＬＬ値に評価される。最も重要なことは、式の適切な評価ではなく、エク スターナル及びリソースのそれぞれの状態変化を追跡することである。この状態 の正確な追跡を確実に行うために、式の評価はできる限り多く行われる。 逆にテストステップ３３５３（第３３Ｃ図）において、式の演算子が代入演算 子である場合には、処理はステップ３３５３に進む。ステップ３３５３において は、実行エンジン８０２（第８図）は、論理流れ図２９００（第２９図）に従っ て式のｌｈｓを式そのものとして評価し、また演算は施さない。ステップ３３５ ４（第３３Ｃ図）から、処理はステップ３３５５に進み、ここでは実行エンジン ８０２（第８図）が論理流れ図２９００（第２９図）に従って式のｒｈｓの評価 を行い、また演算は施さない。処理はステップ３３５５（第３３Ｃ図）からステ ップ３３５６に進み、ここでは実行エンジン８０２（第８図）が、式のｒｈｓの 評価によって生成された項目の値を、式のｌｈｓの評価によって生成された項目 に代入する。ステップ３３５６については、後に論理流れ図３３５６（第４５図 ）に関連して詳細に説明する。ステップ３３５６（第３３Ｃ図）の終了後、処理 は論理流れ図２９０２に従って、即ちステップ２９０２（第２９図）に従って終 了する。 従って、ステップ２８０４（第２８図）においては、実行エンジン８０２（第 ８図）が、論理流れ図２９００（第２９図）に従って式の評価 を行う。式の評価においては、実行エンジン８０２（第８図）が、前に詳しく説 明したように、必要な場合にはエクスターナル及びリソースのそれぞれの状態に 対して演算を施す。前に説明したように、式の評価に際しての演算の適用によっ て生ずる何らかの状態違反は、コンピュータプログラム６１０におけるエラーと してユーザに通知される。宣言の処理 上述のように、宣言ステートメントはステップ２８０８（第２８図）において 処理されるが、このステップ２８０８は論理流れ図２８０８（第３４図）におい て詳細に示されている。宣言ステートメントは、そのフィールド“ｐｏｉｎｔｅ ｒｓ”が２つのポインタの配列であるステートメント構造体１４１６（第２１図 ）のようなステートメント構造体によって表現される。上述のように、宣言ステ ートメントを表現するステートメント構造体の第１ポインタは宣言構造体１５０ ６（第１６図）のような宣言構造体を指定し、第２ポインタは宣言された項目の 初期値を定める式構造体を指定する。 論理流れ図２８０８（第３４図）に従った処理は、ステップ３４０２から開始 され、このステップでは、項目構造体２７００（第２７図）のような項目構造体 が、宣言された項目に対して生成される。生成された項目構造体を指定するポイ ンタは、宣言構造体１５０６のフィールド“ｉｔｅｍ”１６０８（第１６図）に 格納される。フィールド“ｔｙｐｅ ｃｏｄｅ”２７１２（第２７図）は、宣言 において指定されたデータの型に従って、即ち宣言構造体１５０６のフィールド “ｔｙｐｅ”１６０６（第１６図）に従って設定される。フィールド“ｉｎｉｔ ｉａｌｉｚｅｄ”２７１４（第２７図）は、その項目が初期化されていないこと を示すように設定される。 処理はステップ３４０２（第３４図）からテストステップ３４０４に 進み、ここでは実行エンジン８０２（第８図）が、その宣言ステートメントが、 宣言された項目のための初期値を特定しているか否か、即ちその宣言ステートメ ントを表現するステートメント構造体の第２ポインタが、式構造体を指定してい るか、若しくはＮＵＬＬ値であるか判定する。その宣言ステートメントが初期値 を特定していない場合、即ち第２ポインタがＮＵＬＬである場合には、処理は論 理流れ図２８０８（第３４図）に従って終了する。逆にその宣言ステートメント が初期値を特定する式を含んでいる場合、即ち第２ポインタが式ステートメント を指定している場合には、処理はテストステップ３４０４からステップ３４０６ に進む。ステップ３４０６において、実行エンジン８０２（第８図）が、前に詳 しく説明したように、論理流れ図２９００（第２９図）に従って式構造体によっ て表現された式を評価する。論理流れ図２９００に従って式を評価するときに、 演算は施されない。処理はステップ３４０６（第３４図）からステップ３４０８ に進み、そこでは式が評価される項目が宣言された項目に代入される。更に、宣 言された項目を表現する項目構造体のフィールド“ｉｎｉｔｉａｌｉｚｅｄ”２ ７１４（第２７図）が、その項目が初期化されたことを示すように設定される。 ステップ３４０８（第３４図）の終了後、処理は論理流れ図２８０８に従って、 ステップ２８０８（第２８図）に従って終了する。従ってステップ２８０８にお いては、新たな項目が生成され、初期値が指定される場合にはその新たな項目が その初期値を有するように初期化される。決定処理 上述のように、実行エンジン８０２（第８図）は、ステップ２８１２（第２８ 図）において決定処理、即ち“ｉｆ”ステートメントの処理を行う。ここでステ ップ２８１２は論理流れ図２８１２（第３５図）に詳細に示されている。処理は ステップ３５０２から開始されるが、ここで は実行エンジン８０２（第８図）が、論理流れ図２９００（第２９図）に従って “ｉｆ”ステートメントの述語である式の評価を行い、演算ｐを適用する。Ｃ言 語においては、“ｉｆ”ステートメントは述語及び第２ステートメントを含む。 この述語は、第２ステートメントが実行されるか否かを決定するブール値項目に 評価される式である。例えば、ステートメント“ｉｆ（ａ＝＝ｂ）ｃｉ１；”は 、述語、即ち式“ａ＝＝ｂ”が、その値が“ｔｒｕｅ”であるブール値項目に評 価される場合、即ち項目“ａ”が項目“ｂ”と等しい場合にのみ、第２ステート メント、即ちステートメント“ｃｉ１”が実行されるという処理を特定する。項 目“ａ”が項目“ｂ”と等しくない場合には、ステートメント“ｃｉ１”は実行 されない。 処理はステップ３５０２（第３５図）からテストステップ３５０４に進み、こ こでは実行エンジン８０２（第８図）が、述語が既知の値を有する項目に評価さ れたか否かを判定する。実行エンジン８０２はこの判定を、述語の評価によって 生成された項目とＮＵＬＬとを比較することによって行う。上述のように、実行 エンジン８０２が式の評価を適切に行うことができない場合には、式はＮＵＬＬ に評価される。述語が既知の値を有する項目に、即ちＮＵＬＬ以外の値に評価さ れた場合には、処理はテストステップ３５０４（第３５図）からテストステップ ３５０６に進む。 テストステップ３５０６においては、実行エンジン８０２（第８図）が、述語 の評価によって生成された項目の値とブール値“ｔｒｕｅ”とを比較する。述語 が、“ｔｒｕｅ”のブール値を有するブール値項目に評価された場合には、処理 はステップ３５０８（第３５図）に進み、そこで実行エンジン８０２（第８図） が、“ｉｆ”ステートメントの第２ステートメントを実行する。第２ステートメ ントは、前に詳しく説明し たように論理流れ図２８００（第２８図）に従って処理される。従って、論理流 れ図２８００は再帰的に実行される。 一方、述語がブール値“ｆａｌｓｅ”に評価された場合には、処理はテストス テップ３５０６（第２８図）からステップ３５１０に進み、そこで実行エンジン ８０２（第８図）が、後に詳述する制御レコードに、“ｅｌｓｅ”条件を示すデ ータを格納する。制御レコードは、後に詳しく述べるように、サブジェクト関数 の実行のエミュレーションにおいて適切な制御の流れを与えるために用いられる 。ステップ３５０８（第３５図）またはステップ３５１０の何れかが終了した後 、処理は論理流れ図２８１２に従って、即ちステップ２８１２（第２８図）に従 って終了する。 上述のように、実行エンジン８０２（第８図）は、テストステップ３５０４（ 第３５図）において、述語が既知の値に評価された否かを判定する。述語が既知 の値に評価されない場合、即ちＮＵＬＬに評価されるか、未知の値を有する項目 に評価された場合には、処理はテストステップ３５０４からステップ３５１２に 進む。ステップ３５１２において、実行エンジン８０２（第８図）はその述語が 評価されうるブール値をシミュレートする。一実施例においては、実行エンジン ８１２（第８図）は、ブール値“ｔｒｕｅ”またはブール値“ｆａｌｓｅ”から ランダムに選択を行う。ステップ３５１２（第３５図）から、処理はステップ３ ５１４に進む。 ステップ３５１４において、実行エンジン８０２（第８図）は、ステップ３５ １２（第３５図）において選択されたブール値から、できる限り多くの推測を行 う。例えば、述語が式“ａ＆＆ｂ”（即ちａ ＡＮＤ ｂ）であり、述語がブー ル値“ｔｒｕｅ”を有するように選択された場合、実行エンジン８０２（第８図 ）は、項目“ａ”と項目“ｂ”の双方がブ ール値“ｔｒｕｅ”を有するものと推測する。ａ及びｂの双方が“ｔｒｕｅ”の 場合にのみ式“ａ＆＆ｂ”が“ｔｒｕｅ”と評価されることから、この推測がな され得るのである。ステップ３５１４（第３５図）は、論理流れ図３６００（第 ３６図）に従った述語の処理を含んでいる。論理流れ図３６００の各ステップに おいては、その式の評価により得られることが推定される推定ブール値から、式 における値を推測する。“Ｎｏｔ”演算子 論理流れ図３６００に従った処理はテストステップ３６０２から開始されるが 、このステップでは実行エンジン８０２（第８図）が、式の演算値と、“ＮＯｔ ”演算子との比較を行う、即ちその式を表現する式構造体のフィールド“ｋｉｎ ｄ”２２０２（第２２図）と、“Ｎｏｔ”演算子を特定するデータとの比較を行 う。“Ｎｏｔ”演算子（即ち“！”）は、１つのオペランドに対して演算を施し 、演算結果としてそのオペランドの値の論理的否定をその値とする項目を生成す る。例えば、式“！ａ”は、オペランド、即ち式“ａ”の否定である。 式の演算子が“Ｎｏｔ”演算子でない場合には、処理はテストステップ３６０ ２（第３６図）から、以下に説明するテストステップ３６０６に進む。逆に、式 の演算子が“Ｎｏｔ”演算子である場合には、処理はテストステップ３６０２か らステップ３６０６に進む。ステップ３６０６においては、実行エンジン８０２ （第８図）が論理流れ図３６００（第３６図）に従ってオペランドを処理し、推 定値の論理的否定を推定する。例えば、式“！（ａ＆＆ｂ）”、即ちＮＯＴ（ａ ＡＮＤ ｂ）が、“ｔｒｕｅ”と推定された場合には、式“ａ＆＆ｂ”が“ｆ ａｌｓｅ”と推定される。即ち、論理流れ図３６００に従った処理は再帰的に実 行される。ステップ３６０４の終了後、処理は論理流れ図３６００に従って終了 する。“Ａｎｄ”演算子または“Ｏｒ”演算子 上述のように、式の演算子が“Ｎｏｔ”演算子でない場合には、処理はテスト ステップ３６０２（第３６図）からテストステップ３６０６に進む。テストステ ップ３６０６においては、実行エンジン８０２（第８図）が、式の演算子と“Ａ ｎｄ”演算子及び“Ｏｒ”演算子とを比較する。つまり、実行エンジン８０２は 、その式を表現する式構造体のフィールド“ｋｉｎｄ”２２０２（第２２図）と “Ａｎｄ”演算子及び“Ｏｒ”演算子を指定するデータとの比較を行うのである 。上述のように、“Ａｎｄ”演算子及び“Ｏｒ”演算子（即ち“＆＆”及び“｜ ｜”）は、２つのオペランド、即ちｌｈｓ及びｒｈｓに演算を施し、演算結果と して２つのオペランドの値の論理積及び論理和をその値とする項目を生成する。 式の演算子が“Ａｎｄ”演算子でも“Ｏｒ”演算子でもない場合には、処理はテ ストステップ３６０６（第３６図）から、後に説明するテストステップ３６１０ に進む。逆に、式の演算子が“Ａｎｄ”演算子、若しくは“Ｏｒ”演算子の何れ かである場合には、処理はテストステップ３６０６からステップ３６０８に進む 。 ステップ３６０８はテストステップ３７０２から処理が開始される論理流れ図 ３６０８（第３７図）に詳細に示されている。テストステップ３７０２において は、実行エンジン８０２（第８図）が、式の演算子と、“Ａｎｄ”演算子との比 較を行い、更にその式が評価されたときに推定されるブール値、即ち推定値と、 ブール値“ｔｒｕｅ”とを比較する。演算子が“Ａｎｄ”演算子でない場合、若 しくは推定値が“ｔｒｕｅ”でない場合には、処理はテストステップ３７０２か ら、後に説明するテストステップ３７０６に進む。逆に演算子が“Ａｎｄ”演算 子である場合、及び推定値が“ｔｒｕｅ”である場合には、処理はテストステッ プ３７０２からステップ３７０４に進む。 ステップ３７０４においては、各オペランド、即ち式のｌｈｓ及びｒｈｓのそ れぞれが、論理流れ図３６００（第３６図）に従って推定値“ｔｒｕｅ”と共に １つの式として処理される。このような、ｌｈｓ及びｒｈｓの双方が“ｔｒｕｅ ”であるという推測は適切である。というのは、式“ａ＆＆ｂ”が“ｔｒｕｅ” である場合には、両オペランド、即ち式“ａ”及び“ｂ”が共に“ｔｒｕｅ”で なければならないからである。上述のように、Ｃ言語の演算子“＆＆”は論理積 演算を意味する。ステップ３７０４（第３７図）の終了後、処理は論理流れ図３ ６０８に従って、即ちステップ３６０８（第３６図）に従って終了する。 上述のように、演算子が“Ａｎｄ”演算子でなく、若しくは推定値が“ｔｒｕ ｅ”でない場合には、処理はテストステップ３７０２（第３７図）からテストス テップ３７０６に進む。テストステップ３７０６においては、実行エンジン８０ ２（第８図）が、式の演算子と“Ｏｒ”演算子との比較を行い、かつ推定値とブ ール値“ｆａｌｓｅ”との比較を行う。式の演算子が“Ｏｒ”演算子でなく、若 しくは推定値が“ｆａｌｓｅ”でない場合には、処理は論理流れ図３６０８に従 って、即ちステップ３６０８（第３６図）に従って終了する。逆に、演算子が“ Ｏｒ”演算子であり、推定値が“ｆａｌｓｅ”である場合には、処理はテストス テップ３７０６（第３７図）からステップ３７０８に進む。 ステップ３７０８において、各オペランド、即ち式のｌｈｓ及びｒｈｓのそれ ぞれが、論理流れ図３６００（第３６図）に従って、推定値“ｆａｌｓｅ”と共 に１つの式として処理される。このようなｌｈｓ及びｒｈｓが“ｆａｌｓｅ”で あるという推測は適切である。というのは、表現“ａ｜｜ｂ”が“ｆａｌｓｅ” である場合には、両オペランド、即ち“ａ”及び“ｂ”が共に“ｆａｌｓｅ”で なければならないからである。上述のように、Ｃ言語の演算子“｜｜”は、論理 和演算を意味する。ス テップ３７０８（第３７図）の終了後、処理は論理流れ図３６０８に従って、即 ちステップ３６０８（第３６図）に従って終了する。 ステップ３６０８の終了後、処理は論理流れ図３６００に従って終了する。関係演算子 上述のように、式の演算子が“Ａｎｄ”演算子でも、“Ｏｒ”演算子でもない 場合には、処理はテストステップ３６０６からテストステップ３６１０に進む。 テストステップ３６１０においては、実行エンジン８０２（第８図）が式の演算 子と、以下の関係演算子との比較を行う。その関係演算子とは即ち、より小さい （“＜”）、より小さいか若しくは等しい（“＜＝”）、より大きい（“＞”） 、より大きいか若しくは等しい（“＞＝”）、等しい（“＝＝”）、及び等しく ない（“！＝”）という関係を表す演算子である。詳述すると、実行エンジン８ ０２は、その式を表現する式構造体のフィールド“ｋｉｎｄ”２２０２（第２２ 図）と、これらの関係演算子のそれぞれを指定するデータとの比較を行うのであ る。上述のように、関係演算子は、２つのオペランド、即ち式のｌｈｓ及びｒｈ ｓに演算を施し、演算結果として、ｌｈｓとｒｈｓとの関係に対応する値を有す るブール値項目を生成する。式の演算子が関係演算子でない場合には、処理はテ ストステップ３６１０（第３６図）から、後に説明するテストステップ３６１４ に進む。逆に式の演算子が関係演算子である場合には、処理はテストステップ３ ６１０からステップ３６１２に進む。 ステップ３６１２においては、実行エンジン８０２（第８図）が、関係演算子 の評価を行う。ステップ３６１２（第３６図）は、ステップ３８０２から処理が 開始される論理流れ図３６１２（第３８図）に詳細が示されている。ステップ３ ８０２においては、実行エンジン８０２（第 ８図）が、ｌｈｓ及びｒｈｓの双方が既知であるか否か即ち既知の値を有する項 目に評価されるか否かということ、及びｌｈｓ及びｒｈｓの双方が未知であるか 否か、即ち未知の値を有する項目に評価されるか否かということを判定する。項 目構造体２７００（第２７図）によって表現される項目が未知の値を有する場合 には、フィールド“ｔｙｐｅ ｃｏｄｅ”２７１２が項目の型が未知であること を表す。式のｌｈｓ及びｒｈｓの双方が既知であるか、若しくはその双方が未知 の場合には、論理流れ図３６１２（第３８図）に従って、即ちステップ３６１２ （第３６図）に従って処理が終了するが、これは両オペランドが既知である場合 には推測すべきものがなく、また両オペランドが共に未知の場合には推測し得る ものがないからである。逆に、オペランドの一方が既知で他方が未知の場合には 、処理はテストステップ３８０２（第３８図）からテストステップ３８０４に進 む。 テストステップ３８０４においては、実行エンジン８０２（第８図）が、何れ かのオペランドが未定義であるか否かを判定する。オペランドが項目構造体によ って表現される項目に評価されない場合、即ちオペランドがＮＵＬＬ値に評価さ れる場合にはそのオペランドは未定義である。このような場合においては、推測 値を代入すべき項目は存在しない。従って、一方のオペランドが未定義である場 合には、処理は論理流れ図３６１２（第３８図）に従って、即ちステップ３６１ ２（第３６図）に従って終了する。逆に両オペランドが共に定義されている場合 には、処理はテストステップ３８０４（第３８図）から、テストステップ３８０ ６に進む。 テストステップ３８０６においては、実行エンジン８０２（第８図）が、式の 演算子と“＝”演算子及び“ｎｏｔ ｅｑｕａｌ”演算子とを比較し、推定値と ブール値“ｔｒｕｅ”及び“ｆａｌｓｅ”との比較を 行う。（ｉ）式の演算子が“＝”演算子であり、推定値が“ｔｒｕｅ”であると いう条件、及び（ｉｉ）式の演算子が“ｎｏｔ ｅｑｕａｌ”演算子であり、推 定値が“ｆａｌｓｅ”であるという条件の双方が満たされていない場合には、処 理はテストステップ３８０６（第３８図）から後に説明するテストステップ３８ １４に進む。逆に、（ｉ）式の演算子が“＝”演算子であり、推定値が“ｔｒｕ ｅ”であるという条件、及び（ｉｉ）式の演算子が“ｎｏｔ ｅｑｕａｌ”演算 子であり、推定値が“ｆａｌｓｅ”であるという条件の何れか一方が満たされて いる場合には、処理はテストステップ３８０６からテストステップ３８０８に進 む。 テストステップ３８０８において、１つのオペランドが既知の値であり、他方 のオペランドは未知の値を有する。その値が既知であるオペランドは、“ｋｎｏ ｗｎ ｉｔｅｍ”に評価される。その値が未知のオペランドは“ｕｎｋｎｏｗｎ ｉｔｅｍ”に評価される。更に、テストステップ３８０８においては、２つの オペランドが等しい値を有することが推定される。テストステップ３８０８にお いて、実行エンジン８０２（第８図）は、既知の項目がＮＵＬＬ値を有するか否 かを判定する。（ｉ）項目の型が、フィールド“ｔｙｐｅ ｃｏｄｅ”で、即ち 項目構造体２７００のフィールド“ｔｙｐｅ ｃｏｄｅ”２７１２（第２７図） で指定されているように、“ｌｏｎｇ”または“ｐｏｉｎｔｅｒ”の何れかであ ることを示しているという条件、及び（ｉｉ）項目の値が、フィールド“ｖａｌ ｕｅ”において、即ち項目構造体２７００のフィールド“ｖａｌｕｅ”２７０６ において指定されているように、０であることを示しているという条件の双方が 満たされている場合には、その項目はＮＵＬＬ値を有する。 既知の項目がＮＵＬＬ値を有する場合、処理はテストステップ３８０ ８（第３８図）からステップ３８１０に進み、ここでは演算ｘを施すことにより 、その末知の項目に関連するリソースに、無効という印付けがなされる。リソー スが関連付けられた未知の項目の値が、その値がＮＵＬＬである既知の項目に等 しいと推定されることから、即ちそのリソースに対するポインタがＮＵＬＬであ ると推定されることから、このリソースは無効である。 処理はステップ３８１０からステップ３８１２に進む。更に、既知の項目がＮ ＵＬＬ値を有していない場合、処理はテストステップ３８０８から直接ステップ ３８１２に進む。ステップ３８１２においては、既知の項目の値が、以下に詳し く説明する方法で未知の値に代入される。従って、既知の項目の値は、その既知 の項目と未知の項目とが等しいと推定される場合には既知の項目の値から推測さ れる。ステップ３８１２が終了した後、処理は論理流れ図３６１２に従って、即 ちステップ３６１２（第３６図）に従って終了する。 上述のように、（ｉ）式の演算子が、“＝”演算子であり、推定値が“ｔｒｕ ｅ”であるという条件、及び（ｉｉ）式の演算子が“ｎｏｔ ｅｑｕａｌ”演算 子であり、推定値が“ｆａｌｓｅ”であるという条件の双方が満たされない場合 には、処理はテストステップ３８０６（第３８図）からテストステップ３８１４ に進む。テストステップ３８１４においては、実行エンジン８０２（第８図）が 、（ｉ）式の演算子が“ｎｏｔ ｅｑｕａｌ”演算子であり、推定値が“ｔｒｕ ｅ”であるという条件を満たすか否か、または（ｉｉ）式の演算子が“＝”演算 子であり、推定値が“ｆａｌｓｅ”であるという条件を満たすか否かということ を判定する。条件（ｉ）も、条件（ｉｉ）も何れもが満たされない場合には、論 理流れ図３６１２に従って、即ちステップ３６１２（第３６図）に従って処理が 終了する。そうでない場合、即ち条件（ｉ）若しくは条 件（ｉｉ）の何れかが満たされる場合には、処理はテストステップ３８１４（第 ３８図）からテストステップ３８１６に進む。 テストステップ３８１６においては、実行エンジン８０２（第８図）が２つの オペランド、即ちｌｈｓ及びｒｈｓが互いに等しくないことを推測する。既知の 項目がＮＵＬＬ値を有する場合は、未知の項目が非ＮＵＬＬ値を有するものと推 測される。Ｃ言語の様々なインプリメンテーションの文脈においては、ＮＵＬＬ は値ゼロである。従って、未知の項目は非ゼロ値を有するものと推測される。テ ストステップ３８１６（第３８図）においては、実行エンジン８０２（第８図） が、既知の項目の値とＮＵＬＬとを比較する。既知の項目の値がＮＵＬＬでない 場合には、処理は論理流れ図３６１２（第３８図）に従って終了する。逆に、既 知の項目の値がＮＵＬＬである場合は、処理はテストステップ３８１８に進む。 テストステップ３８１８においては、実行エンジン８０２（第８図）が、状態 Ｑにあるリソースが既知の項目に関連付けられているか否かを判定する。上述の ように、リソースが割り当てられた状態、割り当てられていない状態、または無 効状態の何れにあるかが未知である場合には、リソースは状態Ｑにある。未知の 項目が状態Ｑにあるリソースと関連付けられている場合には、処理はステップ３ ８２０（第３８図）に進み、ここでは演算ａが、その未知の項目に関連付けられ たリソースに対して施される。リソースが関連付けられている項目がＮＵＬＬと 等しくないことが推定されていることから、そのリソースを明確に割り当てられ た状態におくために演算ａが施されるのである。ステップ３８２０から、処理は ステップ３８２２に進む。更に、未知の項目が状態Ｑにあるリソースに関連付け られていない場合には、処理はテストステップ３８１８から直接ステップ３８２ ２に進む。 ステップ３８２２において、その未知の項目を表現する項目構造体のフィール ド“ｔｙｐｅ ｃｏｄｅ”２７１２（第２７図）は、その項目が非ゼロであるこ とを示すように設定され、その未知の項目を表現する項目構造体のフィールド“ ｉｎｖａｌｉｄ ｐｏｉｎｔｅｒ”２７２０は、その未知の項目は無効ポインタ 、即ちＮＵＬＬ値を有していないことを示すように設定される。ステップ３８２ ２の終了後、処理は論理流れ図３６１２に従って終了する。 従って、論理流れ図３６１２に従って、即ちステップ３６１２（第３６図）に 従って、その式のオペランドの１つが既知であり、他のオペランドが既知ではな くかつ両オペランドが等しいと推定されるとき、若しくは等しくないと推定され ているときには推測がなされる。推測がなされるのは、式の両オペランドの値、 及び式のオペランドに関連するリソースの状態の双方についてである。ステップ ３６１２が終了した後、処理は論理流れ図３６００に従って終了する。複合演算子 上述のように、式の演算子が関係演算子でない場合には、処理はテストステッ プ３６１０からテストステップ３６１４に進む。テストステップ３６１４におい て、実行エンジン８０２（第８図）は、式の演算子と複合演算子（“，”）とを 比較する。つまり、実行エンジン８０２は、その式を表現する式構造体のフィー ルド“ｋｉｎｄ”２２０２（第２２図）と、複合演算子を指定するデータとの比 較を行うのである。複合演算子は２つのオペランド、即ちｌｈｓ及びｒｈｓに対 して演算を施す。ここでｌｈｓ及びｒｈｓの双方が評価され、式はｒｈｓに評価 される。例えば、式“ａ，ｂ”の評価では、オペランド“ａ”とオペランド“ｂ ”の双方の評価を行った上で、その式“ａ，ｂ”が“ｂ”に評価される。 演算子が複合演算子である場合には、処理はステップ３６１６（第３ ６図）に進み、そこでは実行エンジン８０２（第８図）が論理流れ図３６００（ 第３６図）に従って処理を行い、推定値として、その式が評価されると推定され るブール値を与える。ｒｈｓの値はその式の推定値から推測されるが、これはそ の式がｒｈｓに評価されるからである。例えば、式“ａ＝＝ｂ，ｃ＝＝ｄ”が真 であると推定される場合には、ｒｈＳ、即ち式“ｃ＝＝ｄ”が真であると推測さ れる。従って、処理は論理流れ図３６００に従って、ステップ３６１６において 、処理は論理流れ図３６００に従って再帰的に式のｒｈｓに施される。ステップ ３６１６の終了後、処理は論理流れ図３６００に従って終了する。演算子が複合 演算子でない場合には、処理は論理流れ図３６００に従って終了し、またステッ プ３６１６はスキップされる。 従って、上述のように、論理流れ図３６００に従って、式及び部分式（subexp ression）を再帰的に処理することによって、実行エンジン８０２（第８図）は ステップ３５１４（第３５図）において実行し得る限り、式の推定値から式の項 目及び式の項目に関連するリソースについての推測を行う。処理はステップ３５ １４から前に説明したテストステップ３５０６に進む。 従って、ステップ２８１２（第２８図）において、論理流れ図３８１２に従い 、実行エンジン８０２（第８図）は“ｉｆ”ステートメントにおける決定処理を 行うのである。戻り（return）処理 上述のように“ｒｅｔｕｒｎ”ステートメントはステップ２８１６において処 理される。“ｒｅｔｕｒｎ”ステートメントは、関数の実行を終了し、戻り値項 目が定義されている場合にはその関数の戻り値項目に値を代入する。ステップ２ ８１６は、処理がステップ３９０２から開始される論理流れ図２８１６（第３９ 図）に詳細に示されている。 ステップ３９０２においては、実行エンジン８０２（第８図）が、“ｒｅｔｕ ｒｎ”ステートメントが戻り値項目を指定しているか否かを判定する。“ｒｅｔ ｕｒｎ”ステートメントは、それが式を含んでいる場合、戻り値項目を指定する 。例えば、ステートメント構造体１４１６（第２１図）が“ｒｅｔｕｒｎ”ステ ートメントを表現している場合、フィールド“ｐｏｉｎｔｅｒｓ”２１１０は、 式構造体を指定する１つのポインタであるか、若しくはＮＵＬＬである。“ｒｅ ｔｕｒｎ”ステートメントが戻り値項目を指定する場合、即ちフィールド“ｐｏ ｉｎｔｅｒｓ”２１１０が式構造体を指定している場合、処理はテストステップ ３９０２（第３９図）からステップ３９０４に進み、ここで“ｒｅｔｕｒｎ”ス テートメントの式が論理流れ図２９００（第２９図）に従って評価され、また、 演算は施されない。ステップ３９０４（第３９図）において“ｒｅｔｕｒｎ”ス テートメントの式の評価において演算は施されないが、前にステップ３３０６、 ３３０７、及び３３１４（第３３Ａ図）に関連して説明したように、式のオペラ ンドに何らかの演算を施すことも可能である。ステップ３９０４（第３９図）か ら処理はステップ３９０６に進み、ここでは実行エンジン８０２（第８図）がス テップ３９０４（第３９図）において式の評価を行うことにより生成された項目 を、サブジェクト関数の戻り値項目を表現する項目構造体に代入する。１つの項 目の値を他の項目に代入することに関しては、後に詳しく説明する。 処理はステップ３９０６からステップ３９０８に進む。また、“ｒｅｔｕｒｎ ”ステートメントが戻り値項目を指定していない場合、処理はテストステップ３ ９０２から、直接ステップ３９０８に進む。ステップ３９０８においては、実行 エンジン８０２（第８図）が、後に詳述するように、サブジェクト関数の実行の エミュレーション時においてサブジェクト関数を通る制御の流れを与えるのに用 いられる“ｒｅｔｕｒｎ” 条件を示すデータを、制御レコード内に格納する。ステップ３９０８（第３９図 ）の後、処理は論理流れ図２８１６に従って、即ちステップ２８１６（第２８図 ）に従って終了する。ブロック処理 多くの関数においては、ステートメントのブロックがその関数の挙動を規定す る。Ｃ言語の文脈においては、ステートメントのブロックは、それ自体がブロッ クステートメントである始め括弧、即ち“｛”と、終わり括弧、即ち“｝”との 間に囲まれている。Ｃ言語で規定される関数においては、一般的にステートメン トの第１ブロックが、ステートメントの第２ブロックを含んでいる。例えば、ソ ースコードの抜粋（１）は、第９行から第３２行までのステートメントの第１ブ ロックの中に、第１６行から第２１行までのステートメントの第２ブロックを含 んでいる。このとき、ステートメントの第１ブロックは、ステートメントの第２ ブロックのスーパーブロックであり、ステートメントの第２ブロックはステート メントの第１ブロックのサブブロックである。 （ｐ１１８ｂ）上述のように、ブロックステートメント構造体は、ステートメ ント構造体、即ちブロックの第１ステートメントを表現しているステートメント 構造体１４１６（第２１図）を指定するポインタを含む。ステートメント構造体 １４１６は上述のように、ブロックの各ステートメントを表現するステートメン ト構造体のシングルリンクトリスト（singly-linked list）を維持するために用 いられるフィールド“ｎｅｘｔ”２１０６を含んでいる。上述のように、ブロッ クステートメントはステップ２８２０（第２８図）において処理され、このステ ップ２８２０については論理流れ図２８２０（第４０図）にその詳細が示されて おり、またこの論理流れ図は、ブロックのステートメントの実行のエミュレーシ ョンのためのステートメントのブロックのステートメント構造体 の処理について説明している。 ステップ４００２においては、実行エンジン８０２（第８図）が、ブロックの 第１ステートメントを表現するステートメント構造体を検索する。上述のように 、そのブロックの第１ステートメントを表現するステートメント構造体は、ブロ ックステートメント構造体によって指定されている。検索されたステートメント 構造体は、現ステートメント構造体である。処理はステップ４００２（第４０図 ）からテストステップ４００４に進む。 テストステップ４００４においては、実行エンジン８０２（第８図）が、現ス テートメント構造体が“ｅｌｓｅ”ステートメントを表現し、制御レコードが“ ｅｌｓｅ”条件を示しているか否かを判定する。Ｃ言語においては、“ｅｌｓｅ ”ステートメントは周知のものであり、Ｃスタンダードのセクション６．６．４ ．１に記載されている。ステートメント構造体１４１６（第２１図）のようなス テートメント構造体は、フィールド“ｋｉｎｄ”２１０２がそのように示されて いる場合には、“ｅｌｓｅ”ステートメントを表現する。制御レコードは、サブ ジェクト関数の実行のエミュレーション時に制御の流れを管理するために、実行 エンジン８０２（第８図）内部に維持されている。ステップ３５１０（第３５図 ）に関連して上述したように、制御レコードは、“ｉｆ”ステートメントを処理 するときに“ｅｌｓｅ”条件を示すように設定され、“ｉｆ”ステートメントの 述語がブール値“ｆａｌｓｅ”に評価される。現ステートメント構造体が“ｅｌ ｓｅ”ステートメントを表現していないか、若しくは制御レコードが“ｅｌｓｅ ”条件を示していない場合には、処理はテストステップ４００４（第４０図）か らステップ４００６に進み、ここで現ステートメント構造体によって表現された ステートメントの実行が、上述のように、論理流れ図２８００（第２８図）に従 ってエ ミュレートされる。逆に、現ステートメント構造体が“ｅｌｓｅ”ステートメン トを表現し、かつ制御レコードが“ｅｌｓｅ”条件を示していない場合には、処 理はテストステップ４００４（第４０図）から以下に説明するステップ４０１４ に進み、ステップ４００６はバイパスされる。 上述のように、ステートメントのブロックはサブブロックを含み得る。また、 上述のように、ステップ４００６において、現ステートメント構造体は論理流れ 図２８００（第２８図）に従って処理される。従って、ステップ４００６（第４ ０図）におけるブロックステートメントの実行により、ステップ２８２０（第２ ８図）が再帰的に実行され、従って論理流れ図２８２０（第４０図）の各ステッ プが再帰的に実行されて、サブブロックの実行のエミュレーションが行われる。 ひとたびサブブロックのステートメントが論理流れ図２８２０に従って処理され ると、ステップ４００６におけるブロックステートメントの処理は完了し、サブ ブロックのステートメントの論理流れ図２８２０に従った処理は続行される。処 理はステップ４００６からテストステップ４００８に進む。 テストステップ４００８においては、実行エンジン８０２（第８図）が、論理 流れ図２８００（第２８図）に関連して上述したようにステートメントの実行の エミュレーションによって設定された制御レコードと、“ｒｅｔｕｒｎ”条件、 “ｅｘｉｔ”条件、若しくは“ｌｏｎｇ ｊｕｍｐ”条件を示すデータとの比較 を行う。ステップ３９０８（第３９図）に関連して上述したように、ステップ４ ００６（第４０図）において、“ｒｅｔｕｒｎ”ステートメントの実行のエミュ レーション時に、制御レコードは“ｒｅｔｕｒｎ”条件を示すように設定される 。“ｅｘｉｔ”条件は、実行エンジン８０２（第８図）がライブラリ関数ｅｘｉ ｔ () の呼出しを処理するときに生起する。このライブラリ関数ｅｘｉｔ () に ついては、Ｃスタンダードのセクション７．１０．４．３に記載され ている。“ｌｏｎｇ ｊｕｍｐ”条件は、実行エンジン８０２が、ライブラリ関 数ｌｏｎｇｊｍｐ () の呼出しを処理するときに生起する。このライブラリ関数 ｌｏｎｇｊｍｐ () についてもＣスタンダードのセクション７．６．２．１に記 載されている。制御レコードが“ｒｅｔｕｒｎ”条件、“ｅｘｉｔ”条件、若し くは“ｌｏｎｇ ｊｕｍｐ”条件を示している場合、処理は論理流れ図２８２０ （第４０図）に従って終了する。逆に制御レコードが“ｒｅｔｕｒｎ”条件、“ ｅｘｉｔ”条件、若しくは“ｌｏｎｇ ｊｕｍｐ”条件の何れをも示していない 場合には、処理はテストステップ４００８からテストステップ４０１０に進む。 テストステップ４０１０においては、実行エンジン８０２（第８図）が制御レ コードと、“ｂｒｅａｋ”条件若しくは“ｃｏｎｔｉｎｕｅ”条件を示すデータ とを比較する。ステップ４００６においては、“ｂｒｅａｋ”ステートメント若 しくは“ｃｏｎｔｉｎｕｅ”ステートメントの実行のエミュレーション時に、制 御レコードが、“ｂｒｅａｋ”条件若しくは“ｃｏｎｔｉｎｕｅ”条件を示すよ うに設定される。制御レコードが“ｂｒｅａｋ”条件若しくは“ｃｏｎｔｉｎｕ ｅ”条件の何れかを示すように設定されている場合、処理はステップ４０１０に 進み、ここで制御レコードが“ｎｅｘｔ”条件を示すように設定され、処理は論 理流れ図２８２０に従って終了する。 “ｎｅｘｔ”条件は、ブロックの“ｎｅｘｔ”ステートメントの実行がエミュ レートされる場合の一般的な処理条件である。従って、ステートメントの現ブロ ックが“ｂｒｅａｋ”ステートメントを実行する場合、現ブロックの処理は終了 し、処理は現ブロックのスーパーブロック内における現ブロックのすぐ後に続く ステートメントに進む。これに対して、“ｒｅｔｕｒｎ”条件は制御レコードを リセットしない。従って、ステップ４００６における“ｒｅｔｕｒｎ”ステート メントの実行のエミュ レーションにより、上述のテストステップ４００８を通した現ブロックの処理が 終了し、同様に現ブロックの任意のスーパーブロックの処理も終了する。 一方、制御レコードが“ｂｒｅａｋ”条件も“ｃｏｎｔｉｎｕｅ”条件をも示 していない場合には、処理はテストステップ４０１０からステップ４０１４に進 む。更に、現ステートメント構造体が“ｅｌｓｅ”ステートメントを表現し、制 御レコードが上述のように“ｅｌｓｅ”条件を示していない場合には、処理はテ ストステップ４００４から４０１４に進む。ステップ４０１４においては、実行 エンジン８０２（第８図）が現ステートメント構造体のフィールド“ｎｅｘｔ” ２１０６（第２１図）を検索し、検索されたステートメント構造体を現ステート メント構造体にして、前の現ステートメント構造体を置き換える。 処理はステップ４０１４（第４０図）からテストステップ４０１６に進み、こ こで実行エンジン８０２（第８図）が、現ステートメント構造体を指定するポイ ンタとＮＵＬＬとを比較する。現ステートメント構造体を指定するポインタがＮ ＵＬＬである場合には、ステートメントのブロックの最終ステートメントが論理 流れ図２８２０（第４０図）に従って処理され、処理は論理流れ図２８２０に従 って終了する。逆に、現ステートメント構造体を指定するポインタがＮＵＬＬで ない場合には、処理はテストステップ４０１６から、上述のテストステップ４０ ０４に進む。 従って、ステートメントのブロックの実行はエミュレートされ、ステートメン トのブロックにおける制御の流れは、論理流れ図２８２０（第４０図）の通りに 流れることになる。リークの処理 上述のように、サブジェクト関数のステートメントの実行がひとたび エミュレートされると、ステップ２６０６（第２６図）においてリーク（leak） が検出される。ステップ２６０６については論理流れ図２６０６（第４１図）に その詳細が示されている。処理は論理流れ図２６０６に従ってループステップ４ １０２から開始される。ループステップ４１０２及びＮＥＸＴステップ４１０６ はループを形成し、その中でサブジェクト関数の各エクスターナルがステップ４ １０４に従って処理される。ステップ４１０４においては、実行エンジン８０２ （第８図）が、エクスターナルが到達可能な全てのリソースに印付けを行う（ｍ ark）。そのリソースがエクスターナル若しくはそのエクスターナルを含む集群 （bunch）における任意の項目に関連付けられている場合には、そのリソースは エクスターナルが到達可能なリソースである。集群については以下に詳しく説明 する。説明のための例を用いると、集群型である配列の要素が関連付けられたリ ソースは、その配列の任意の要素から到達可能である。 リソース、即ちリソース状態構造体３１００（第３１図）によって表現された リソースは、リソース状態構造体３１００のフィールド“ｍａｒｋ”３１１４を 、それを示すように設定することによって印付けされる。各エクスターナルによ って到達可能な各リソースが、ループステップ４１０２（第４１図）及びＮＥＸ Ｔステップ４１０６によって形成されたループの中でひとたび印付けされると、 処理はループステップ４１０６からループステップ４１０８に進む。 ループステップ４１０８及びＮＥＸＴステップ４１１４はループを形成し、そ の中で各リソースが処理される。リソース状態構造体は、シングルリンクトリス トに保持されて、全てのリソース状態構造体の処理を容易にする。例えば、リソ ース状態構造体３１００（第３１図）は、シングルリンクトリストにおける次の リソース状態構造体を指定するフィ ールド“ｎｅｘｔ”３１１２を含む。メモリ１０４（第１図）内のリソース状態 構造体によって表現される各リソースに対して、処理はループステップ４１０８ （第４１図）からテストステップ４１１０に進む。 テストステップ４１１０においては、実行エンジン８０２（第８図）がリソー スが割り当てられているか否か、即ち状態Ａ若しくは状態Ｑにあるか否かという ことと、印付けされていないことを判定する。割り当てられ印付けされていない リソース、即ちどのエクスターナルからのも到達可能でないリソースはリークと なっている。そのリソースが割り当てられており、かつ印付けされていない場合 には、処理はテストステップ４１１０（第４１図）からステップ４１１２進み、 ここでそのリークがユーザに対して通知される。そのリソースが割り当てられて いない、即ち状態Ａ若しくは状態Ｑにないか、若しくは印付けされている場合に は、処理はテストステップ４１１０から直接ＮＥＸＴステップ４１１４に進む。 更に、処理はステップ４１１２からＮＥＸＴステップ４１１４へ進む。処理はＮ ＥＸＴステップ４１１４からループステップ４１０８に進み、そこで次のリソー スが上述のように処理されて、最終的に全てのリソースが処理される。ひとたび 各リソースが、ループステップ４１０８及びＮＥＸＴステップ４１１４が形成す るループにおいて処理されると、論理流れ図２６０６に従って、即ちステップ２ ６０６（第２６図）に従って処理は終了する。 従って、リークは検出され、論理流れ図２６０６に従って、即ちステップ２６ ０６（第２６図）に従ってそれが通知される。エクスターナルの構築 上述のように、ステップ２６０８において、各エクスターナルは論理流れ図４ ２００（第４２図）に従って構築される。論理流れ図４２００に従った処理はテ ストステップ４２０２から開始されるが、このステッ プでは実行エンジン８０２（第８図）が、リソースがそのエクスターナルに関連 付けられているか否かを判定する。説明のための例を用いて、エクスターナルリ スト構造体１４１４（第１５図）によって表現されたエクスターナルにリソース が関連付けられているか否かの判定について以下説明する。フィールド“ｆｉｒ ｓｔ ｄｅｃｌ”１５０２は宣言構造体１５０６を指定しこの宣言構造体はフィ ールド“ｉｔｅｍ”１６０８を含む。フィールド“ｉｔｅｍ”１６０８は項目構 造体、即ち項目構造体２７００を指定する。項目構造体２７００のフィールド“ ｒｅｓｏｕｒｃｅ”２７０２（第２７図）が、リソース状態構造体を指定してい る場合、エクスターナルリスト構造体１４１４（第１５図）によって表現された エクスターナルに、リソースは関連付けられている。そのエクスターナルが、例 えばリソース状態構造体３１００（第３１図）によって表現されたリソースに関 連付けられている場合、処理はテストステップ４２０２（第４２図）からステッ プ４２０４に進み、ここでフィールド“ｓｔａｔｅ”３１０２（第３１図）が検 索される。処理はステップ４２０４から後に説明するステップ４２１０に進む。 そのエクスターナルに関連付けられたリソースが存在しない場合には、処理は テストステップ４２０２からテストステップ４２０６に進む。テストステップ４ ２０６においては、実行エンジン８０２（第８図）が、そのエクスターナルが無 効ポインタであるか否かを判定する。エクスターナルの型は、そのエクスターナ ルに関連付けられた項目を表現する項目構造体のフィールド“ｔｙｐｅ ｃｏｄ ｅ”２７１２（第２７図）によって指定され、それがＶＡＬＵＥ ＴＹＰＥ Ｎ ＯＮ ＺＥＲＯである場合には、そのエクスターナルは無効ポインタである。型 ＶＡＬＵＥ ＴＹＰＥ ＮＯＮ ＺＥＲＯは、その項目がゼロ以外の値を有する ことを示す。そのエクスターナルに関連付けられた項目を表す項目構造体 のフィールド“ｉｎｖａｌｉｄ ｐｏｉｎｔｅｒ”、即ちフィールド“ｉｎｖａ ｌｉｄ ｐｏｉｎｔｅｒ”２７２０がそれを示している場合、若しくはそのエク スターナルの値が０または−１である場合には、エクスターナルは無効ポインタ である。 そのエクスターナルが無効ポインタである場合には、処理はテストステップ４ ２０４（第４２図）からステップ４２０８に進み、そこでそのエクスナルのリソ ースの状態が状態Ｘに設定される。例えば、リソース状態構造体３１００（第３ １図）によって表現されるリソースが、エクスターナル状態構造体３０００（第 ３０図）によって表現されたエクスターナルに関連付けられている場合には、状 態Ｘを示すデータがフィールド“ｓｔａｔｅ”３１０２（第３１図）に格納され る。ステップ４２０８（第４２図）から、処理はステップ４２１０に進む。更に 、処理は、上述のようにステップ４２０４から、またエクスターナルが無効ポイ ンタでない場合にはテストステップ４２０６からステップ４２１０に進む。 ステップ４２１０において、エクスターナルの複合ＲＳ，ＤＫ及びＣＰ状態が 更新される。状態の構成は、第３Ｂ図、第４Ｂ図、及び第５Ｂ図に関連して前に 詳しく説明した。ステップ４２１０の終了後、処理は論理流れ図４２００に従っ て終了する。関数の出力モデル 上述のように、モデルマシン８０８（第８図）は、ステップ２４１２（第２４ 図）においてサブジェクト関数のモデルを生成し、格納する。ステップ２４１２ は、論理流れ図２４１２（第４３図）に詳細が示されている。処理はステップ４ ３０２から開始され、ここではモデルマシン８０８（第８図）が関数モデル構造 体１１００（第１１図）のような関数モデル構造体の割り当て及び初期化を行う 。関数モデル構造体１１００は、一実施例においては、フィールド“ｎａｍｅ” １１０２、フィー ルド“ｄｅｓｃｒｉｐｔｉｏｎ”１１０８、フィールド“ｆｉｌｅ”１１１０、 フィールド“ｌｉｎｅ”１１１２、及びフィールド“ａｕｔｏｍａｔｅｄ”１１ ０６に、（ｉ）その挙動が関数モデル構造体１１００においてモデル化されてい る関数の識別子、（ｉｉ）その関数のテキスト形式の記述、（ｉｉｉ）ソースコ ードファイルの名称、（ｉｖ）その関数が定義されているソースコードファイル 内の行、及び（ｖ）その関数が自動的にモデル化されたことを示すブール値を、 それぞれ格納することによって初期化される。その関数のモデルがモデルマシン ８０８（第８図）によって生成された場合、関数は自動的にモデル化される。逆 に、その関数のモデルが、ユーザがコンピュータ１００（第１図）においてテキ ストエディタ（図示せず）を用いて生成した場合、その関数は手動でモデル化さ れる。例えば、ライブラリ関数ｆｏｐｅｎ () 、ｍａｌｌｏｃ () 、及びｆｒｅ ｅ () は、手動でモデル化される。関数モデル構造体のフィールド“ａｕｔｏｍ ａｔｅｄ”１１１６（第１１図）は、上述のようにステップ９０４（第９図）に おいてモデル記述ファイル６０４（第６図）から呼出しを行うが、これはその関 数が手動でモデル化されるということを示すように設定される。 ステップ４３０６（第４３図）から、処理はステップ４３０４に進み、そこで エクスターナルモデル構造体１２００（第１２図）のようなエクスターナルモデ ル構造体が、そのサブジェクト関数の各エクスターナルに対して生成され、対応 する関数モデル構造体におけるエクスターナルモデル構造体のシングルリンクト リストに挿入される。例えば、フィールド“ｆｉｒｓｔ ｅｘｔｅｒｎａｌ”１ １０４（第１１図）及びフィールド“ｌａｓｔ ｅｘｔｅｒｎａｌ”１１０６は 、上述のように、関数モデル構造体１１００をエクスターナルモデル構造体のシ ングルリンクトリストに関連付けるために用いられる。１つのエクスターナルの 処 理は、ステップ４３０４（第４３図）に従って行われるが、この処理は論理流れ 図４４００（第４４図）に示されている。 論理流れ図４４００に従って処理はステップ４４０２から開始されるが、ここ ではモデルマシン８０８（第８図）がエクスターナルの型、即ちそのエクスター ナルがパラメータであるか、戻り値項目であるか、若しくは項目（即ち、グロー バルに定義された項目またはスタティックな項目）であるかを判定する。そのエ クスターナルがパラメータである場合は、モデルマシン８０８（第８図）はサブ ジェクト関数の定義におけるパラメータの位置を判定する。第１パラメータはパ ラメータ番号ゼロであって、最終パラメータの番号は、サブジェクト関数に対し て定義されたパラメータ番号より１小さい。そのエクスターナルが項目である場 合には、モデルマシン８０８（第８図）がその項目の識別子を判定する。そのエ クスターナルの型は、上述のように、エクスターナルモデル構造体１２００（第 １２図）のフィールド“ｔｙｐｅ”１２０４に格納される。同様に、パラメータ 番号が求められた場合には、そのパラメータ番号はフィールド“ｐａｒａｍｅｔ ｅｒ ｎｕｍｂｅｒ”１２０６に格納され、項目が求められた場合には、その項 目の識別子がフィールド“ｎａｍｅ”１２０８に格納される。 処理はステップ４４０２からステップ４４０４に進み、そこではモデルマシン ８０８（第８図）が演算の数を判定し、サブジェクト関数の実行のエミュレーシ ョン時に、エクスターナルに施される特定の演算を判定する。ステップ４４０４ においては、演算及び施される演算の数が、そのエクスターナルの複合ＤＫ状態 に従って判定される。次の表Ｎはエクスターナルの複合ＤＫ状態から導かれる演 算及び演算の数の概要を示したものである。 従って、例えば、エクスターナルの複合ＤＫ状態が状態Ａである場合には、サ ブジェクト関数の実行のエミュレーションにおいて、演算ａがそのエクスターナ ルに施される。また、エクスターナルの複合ＤＫ状態が状態ＫＱである場合には 、サブジェクト関数の実行のエミュレーションにおいて、演算ｋが、次いで演算 ｍがそのエクスターナルに施される。上述のように、エクスターナルの複合状態 は、サブジェクト関数の実行の多重エミュレーションの包括的な効果を特定する 。従って、エクスターナルの複合状態から導かれた演算は、そのエクスターナル 上でのサブジェクト関数の実行の累積的な効果のエッセンス（distillation）を 表現する。 処理は、ステップ４４０４からテストステップ４４０６に進み、このステップ ではモデルマシン８０８（第８図）がそのエクスターナルに施される演算の数と ゼロとの比較を行う。そのエクスターナルに施される演算の数がゼロに等しい場 合には、処理はステップ４４０８（第４４図）に進み、そこでモデルマシン８０ ８（第８図）が演算の数を判定し、かつそのエクスターナルの複合ＣＰ状態に従 ったサブジェクト関数のエミュレーション時にそのエクスターナルに施される特 定の演算を求める。以下の表Ｏは、エクスターナルの複合ＣＰ状態から導かれる 演算及び演算の数の概要を示したものである。 従って、エクスターナルの複合ＤＫ状態による、そのエクスターナル上でサブ ジェクトルーチンの実行の累積的効果に関する情報の供給が不十分である場合に は、そのエクスターナルの複合ＣＰ状態が、サブジェクト関数の実行の累積的効 果を判定するために用いられる。説明のための例を用いると、エクスターナルの 複合ＣＰ状態が状態ｉである場合、サブジェクト関数のエミュレーションにより 、そのエクスターナルに演算ｉが施される。ステップ４４０４（第４４図）また はステップ４４０８の何れかにおいて、そのエクスターナルに施される演算及び 演算の数は、エクスターナルモデル構造体１２０のフィールド“ｏｐｅｒａｔｉ ｏｎｓ”１２１４（第１２図）及び“ｎｕｍｂｅｒ ｏｆ ｏｐｅｒａｔｉｏｎ ｓ”１２１２にそれぞれ格納される。処理はステップ４４０８（第４４図）から ステップ４４１０に進む。更に、モデルマシン８０８（第８図）が、テストステ ップ４４０６（第４４図）において、ステップ４４０４において判定されたよう にそのエクスターナルに施される演算の数がゼロであると判定された場合、処理 はテストステップ４４０６から直接ステップ４４１０に進む。 ステップ４４１０において、モデルマシン８０８（第８図）は、エクスターナ ルの複合ＲＳ状態から、そのエクスターナルに関連付けられたリソースの初期状 態を判定する。つまり、そのエクスターナルの複合ＲＳ状態はエクスターナルモ デル構造体１２００のフィールド“ｉｎｉｔ ｉａｌ ｓｔａｔｅ”１２２０（第１２図）に格納される。エクスターナルの複 合ＲＳ状態は、そのエクスターナルに関連するリソースに対するサブジェクト関 数の実行の累積的効果を反映する。処理はステップ４４１０（第４４図）からテ ストステップ４４１２に進み、そこではモデルマシン８０８（第８図）が、その エクスターナルの複合ＲＳ状態と、そのエクスターナルに関連付けられたリソー スが存在しないことを示す状態ＮＯＮＥとを比較する。そのエクスターナルに関 連付けられたリソースが存在しない場合、処理はテストステップ４４１２（第４ ４図）からステップ４４１４に進み、そこではブール値“ｆａｌｓｅ”が、エク スターナルモデル構造体１２００のフィールド“ｎｅｗ ｒｅｓｏｕｒｃｅ”１ ２１８（第１２図）に格納される。逆に、リソースがそのエクスターナルに関連 付けられている場合、即ちそのエクスターナルの複合ＲＳ状態がＮＯＮＥ以外で ある場合には、処理はテストステップ４４１２（第４４図）からステップ４４１ ６に進む。ステップ４４１６においては、モデルマシン８０８（第８図）がエク スターナルモデル構造体１２００のフィールド“ｎｅｗ ｒｅｓｏｕｒｃｅ”１ ２１８（第１２図）にブール値“ｔｒｕｅ”を格納し、サブジェクト関数のエミ ュレーションにより、そのエクスターナルに関連付けられた新たなリソースが生 成されることを示すようにする。 処理はステップ４４１４（第４４図）、若しくはステップ４４１６の何れかか らステップ４４１８に進み、そこでモデルマシン８０８（第８図）がエクスター ナルモデル構造体１２００（第１２図）を、関数モデル構造体１１００（第１１ 図）のエクスターナルモデル構造体のシングルリンクトリストに挿入する。ステ ップ４４１８（第４４図）の終了後、処理は論理流れ図４４００に従って終了す る。 サブジェクト関数の各エクスターナルが、ステップ４３０４（第４３ 図）において論理流れ図４４００に従って処理された後、処理はステップ４３０ ６に進み、そこでサブジェクト関数を表現する関数モデル構造体１１００（第１ １図）が、全ての関数モデル構造体を含むデータ構造体に格納される。ステップ ４３０６の終了後、処理は論理流れ図２４１２に従って、即ちステップ２４１２ （第２４図）に従って終了する。次いで、格納された関数モデル構造体によって 表現される関数モデルが、後に詳しく説明するようにサブジェクト関数の呼出し を行う他の関数の解析を行うときに、そのサブジェクト関数の実行をエミュレー トするために用いられ得る。１つの項目の値の他の項目への代入 上述のように、ステップ３３５６（第３３Ｃ図）において、一方の項目、即ち ｒｈｓの値が、他の項目、即ちｌｈｓに代入される。ステップ３３５６は、論理 流れ図３３５６（第４５図）に詳細に示されており、ここでは、処理がテストス テップ４５０２から開始される。テストステップ４５０２においては、実行エン ジン８０２（第８図）が、ｌｈｓ及びｒｈｓが項目によって表現されるか否かを 判定する。上述のように、ｌｈｓ若しくはｒｈｓ等の式は、実行エンジン８０２ がその式を評価するための十分な情報を有している場合には１つの項目に評価さ れ、他の場合にはＮＵＬＬ値に評価される。式が１つの項目に評価される場合に は、その式はその項目によって表現される。ｌｈｓ若しくはｒｈｓの何れかが１ つの項目によって表現されない場合には、処理はテストステップ４５０２（第４ ５図）から、以下に説明するテストステップ４５１０に進む。逆にｌｈｓ及びｒ ｈｓの双方が１つの項目によって表現される場合には、処理はテストステップ４ ５０２からステップ４５０４に進む。 ステップ４５０４においては、ｌｈｓを表現する項目、即ちｌｈｓ項目のフィ ールドが、それに対応するｒｈｓを表現する項目、即ちｒｈｓ 項目と等しく形成される。詳述すると、項目構造体２７００フィールド“ｒｅｓ ｏｕｒｃｅ”２７０２（第２７図）、“ｅｘｔｅｒｎａｌ”２７０４、“ｖａｌ ｕｅ”２７０６、“ｔｙｐｅ ｃｏｄｅ”２７１２、“ｉｎｉｔｉａｌｉｚｅｄ ”２７１４、及び“ｉｎｖａｌｉｄ ｐｏｉｎｔｅｒ”２７２０のそれぞれに対 応するｒｈｓ項目のフィールドに、データが格納される。処理はステップ４５０ ４（第４５図）からテストステップ４５０に進み、そこでは実行エンジン８０２ （第８図）がｒｈｓが初期化されたか否かを判定する。実行エンジン８０２は、 項目構造体２７００のフィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４（第２７ 図）に対応するｒｈｓ項目のフィールドと、ブール値“ｆａｌｓｅ”とを比較す ることによってこのような判定を行う。 ｒｈｓが初期化されている場合、即ち項目構造体２７００のフィールド“ｉｎ ｉｔｉａｌｉｚｅｄ”２７１４（第２７図）に対応するｒｈｓ項目のフィールド が、ブール値“ｔｒｕｅ”を有している場合には、処理は論理流れ図３３５６に 従って、即ちステップ３３５６（第３３Ｃ図）に従って終了する。逆に、ｒｈｓ が初期化されていない場合、即ち項目構造体２７００のフィールド“ｉｎｉｔｉ ａｌｉｚｅｄ”２７１４（第２７図）に対応するｒｈｓ項目のフィールドがブー ル値“ｆａｌｓｅ”を有している場合には、処理はテストステップ４５０６（第 ４５図）からステップ４５０８に進む。ステップ４５０８においては、上述のよ うにエラーメッセージがエラーログファイル及び／若しくはビデオモニタ１１８ 上のディスプレイに対して送られて、初期化されていないデータが使用されてい ることを警告する。フィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４（第２７図 ）に対応するｒｈｓ項目のフィールドが、上述のようにステップ４５０４におい て、ｌｈｓ項目における対応するフィールドにコピーされることから、ｌｈｓ項 目も初期化されていない旨の 印付けがなされる。ステップ４５０８（第４５図）が終了した後、論理流れ図３ ３５６に従って、即ちステップ３３５６（第３３Ｃ図）に従って処理を終了する 。 上述のように、ｌｈｓ若しくはｒｈｓの何れかが項目によって表現されない場 合、処理はテストステップ４５０２（第４５図）からテストステップ４５１０に 進む。テストステップ４５１０において、実行エンジン８０２（第８図）が、ｒ ｈｓ及びｌｈｓが個別に項目によって表現されるか否かを判定する。ｌｈｓが項 目によって表現され、ｒｈｓが項目によって表現されない場合には、処理はテス トステップ４５１０（第４５図）からステップ４５１２に進む。そうでない場合 には、処理は論理流れ図３３５６に従って、即ちステップ３３５６（第３３Ｃ図 ）に従って終了する。 ステップ４５１２（第４５図）においては、実行エンジン８０２（第８図）が ｌｈｓ項目に未知なものとしての印付けを行う。例えば、項目構造体２７００（ 第２７図）がｌｈｓ項目を表現する場合、実行エンジン８０２（第８図）が、（ ｉ）未知のデータの型を示すデータをフィールド“ｔｙｐｅ ｃｏｄｅ”２７１ ２（第２７図）に格納し、（ｉｉ）ｌｈｓ項目が初期化されていないことを示す データをフィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４に格納し、（ｉｉｉ） ｌｈｓがエクスターナル若しくはリソースと関連付けられていないことを示すべ くフィールド“ｒｅｓｏｕｒｃｅ”２７０２及び“ｅｘｔｅｒｎａｌ”２７０４ にＮＵＬＬを格納することによって、ｌｈｓが既知でないという印付けを行う。 ステップ４５１２（第４５図）の終了後、処理は論理流れ図３３５６に従って、 即ちステップ３３５６（第３３Ｃ図）に従って終了する。 従って、ステップ３３５６において、ｒｈｓを表現する項目の値はｌ ｈｓを表現する項目に代入される。上述のように、実行エンジン８０２（第８図 ）が、ステップ３４０８（第３４図）において式の評価によって得られた項目の 値を、宣言された項目に代入する。ステップ３４０８におけるこの代入は、論理 流れ図３３５６（第４５図）に関連して上述したｒｈｓ項目のｌｈｓ項目への代 入に類似したものである。ステップ３８１２（第３８図）に関して上述したよう に、実行エンジン８０２（第８図）は、既知の項目の値を未知の項目に代入する 。ステップ３８１２（第３８図）における既知の項目の未知の項目への代入は、 論理流れ図３３５６に関連して上述したｒｈｓ項目のｌｈｓ項目への代入に類似 したものである。上述のように、実行エンジン８０２（第８図）は、ステップ３ ９０６（第３９図）において、式の評価によって得られた項目の値を戻り値項目 に代入する。ステップ３９０６におけるこの代入処理は、論理流れ図３３５６（ 第４５図）に関連して上述したｒｈｓ項目のｌｈｓ項目への代入に類似したもの である。関数のエミュレーション 上述のように、実行エンジン８０２（第８図）は、ステップ３３５２（第３３ Ｃ図）において、関数の実行をエミュレートすることにより関数の呼出しを評価 する。ステップ３３５２は論理流れ図３３５２（第４６図）に詳細に示されてお り、ここでは処理がステップ４６０２から始まる。関数の呼出しの実行は、呼び 出される関数の挙動を表現する関数モデル構造体に従ってエミュレートされる。 テストステップ４６０２において、実行エンジン８０２（第８図）は、呼び出さ れる関数の挙動を表現する関数モデル構造体が、メモリ１０４（第１図）に格納 されているか否かを判定する。上述のように、関数モデル構造体１１００（第１ １図）は、関数モデル構造体１１００によってその挙動が表現される関数の識別 子を表現するデータを含んでいるフィールド“ｎａｍｅ”１１ ０２を有する。各関数の挙動を表現する様々な関数モデル構造体の対応するフィ ールドは、サブジェクト関数がその関数を呼び出すのに用いる識別子と比較され るが、これは全ての関数モデル構造体がチェックされるまでか、若しくはそのフ ィールド“ｎａｍｅ”が識別子と一致する関数モデル構造体が見つけられるまで 続けて行われる。 その識別子と一致するフィールド“ｎａｍｅ”を有する関数モデル構造体が見 つけられない場合は、処理はテストステップ４６０２（第４６図）からステップ ４６０４に進み、ここで呼び出される関数の実行のエミュレーションを評価する ことによって得られる項目としてＮＵＬＬが生成される。上述のように、実行エ ンジン８０２（第８図）がその式を適切に評価するための十分な情報を有してい ないときには、式はＮＵＬＬに評価される。ステップ４６０４（第４６図）の実 行の後、処理は論理流れ図３３５２に従って、即ちステップ３３５２（第３３Ｃ 図）に従って終了する。 一方、そのフィールド“ｎａｍｅ”が、サブジェクト関数が関数の呼出しに用 いる識別子と一致するような関数モデル構造体、即ち呼び出される関数の挙動を 表現する関数モデル構造体が見つけれられた場合には、処理はテストステップ４ ６０２（第４６図）からループステップ４６０６に進む。ループステップ４６０ ６及びＮＥＸＴステップ４６３０はループを形成し、このループの中で呼び出さ れる関数の関数モデル構造体内のエクスターナルモデル構造体によって表現され る各エクスターナルが処理される。第１３図に関連して以前に説明したように、 関数モデル構造体１１００Ａのような関数モデル構造体は、エクスターナルモデ ル構造体のシングルリンクトリストにおける第１エクスターナルモデル構造体を 指定するフィールド“ｆｉｒｓｔ ｅｘｔｅｒｎａｌ”１１０４Ａを含む。呼び 出される関数の関数モデル構造体のエクスターナルモデ ル構造体のシングルリンクトリストの各エクスターナルに対して、処理はループ ステップ４６０６（第４６図）からテストステップ４６０８に進む。呼び出され る関数の関数モデル構造体のエクスターナルモデル構造体のシングルリンクトリ ストの各エクスターナルが処理された後、処理はループステップ４６０６から以 下に詳細に説明するステップ４６３２に進む。 以下のステップ４６０８〜４６２８の説明の文脈においては、ループステップ ４６０６及びＮＥＸＴステップ４６３０により形成されるループに従って処理さ れるエクスターナルモデル構造体には、エクスターナルモデル構造体の処理の説 明のための例として、エクスターナルモデル構造体１２００（第１２図）を用い るものとする。テストステップ４６０８（第４６図）において、実行エンジン８ ０２（第８図）が、エクスターナルモデル構造体１２００（第１２図）がパラメ ータを表現しているか否かを、フィールド“ｔｙｐｅ”１２０４とパラメータを 示すデータとを比較することによって判定する。エクスターナルモデル構造体１ ２００がパラメータを表現していない場合には、処理はテストステップ４６０８ （第４６図）から以下に詳細に説明するテストステップ４６１２に進む。逆に、 エクスターナルモデル構造体１２００（第１２図）がパラメータを表現している 場合には、処理はテストステップ４６０８（第４６図）からステップ４６１０に 進む。 ステップ４６１０においては、実行エンジン８０２（第８図）がそのパラメー タを表現する項目を検索する。ループステップ３３４８（第３３Ｃ図）、ステッ プ３３４９、及びＮＥＸＴステップ３３５０に関連して以前に説明したように、 実行エンジン８０２（第８図）は、呼び出される関数のパラメータを表現する項 目の配列を含む。エクスターナルモデル構造体１２００（第１２図）によって表 現される特定のパラメータ は、フィールド“ｐａｒａｍｅｔｅｒ ｎｕｍｂｅｒ”１２０６において指定さ れる。処理はステップ４６１０（第４６図）から、後に詳述するテストステップ ４６１６に進む。 上述のように、エクスターナルモデル構造体１２００（第１２図）がパラメー タを表現していない場合、処理はテストステップ４６０８からテストステップ４ ６１２に進む。テストステップ４６１２（第４６図）において、実行エンジン８ ０２（第８図）が、エクスターナルモデル構造体１２００（第１２図）が変数を 表現しているか否かを、フィールド“ｔｙｐｅ”１２０４内に格納されたデータ と変数が表現されていることを示すデータとを比較することによって判定する。 エクスターナルモデル構造体１２００（第１２図）が変数を表現していない場合 には、処理はテストステップ４６１２（第４６図）から後に詳述するテストステ ップ４６１６に進む。逆に、エクスターナルモデル構造体１２００（第１２図） が変数を表現している場合には、処理はテストステップ４６１２からステップ４ ６１４に進む。 ステップ４６１４において、実行エンジン８０２（第８図）は、エクスターナ ルモデル構造体１２００（第１２図）によって表現される変数の評価を行う。実 行エンジン８０２（第８図）は、その変数の項目を検索することによってその変 数を評価する。サブジェクト関数を表現する関数構造体内において宣言構造体、 即ち宣言構造体１５０６（第１６図）が、エクスターナルモデル構造体１２００ （第１２図）によって表現される変数を表現する。エクスターナルモデル構造体 １２００はその変数の識別子をフィールド“ｎａｍｅ”１２０８に格納すること によって、表現された特定の変数を識別する。エクスターナルモデル構造体１２ ００及び宣言構造体１５０６（第１６図）が同じ変数を表現している場合には、 フィールド“ｎａｍｅ”１６０４に格納された識別子はフィール ド“ｎａｍｅ”１２０（第１２図）に格納された識別子と同じものである。宣言 構造体１５０６の“ｉｔｅｍ”１６０８が指定する項目構造体２７００を検索す ることによってその変数の評価が行われる。処理はステップ４６１４（第４６図 ）からテストステップ４６１６に進む。 上述のように、エクスターナルモデル構造体１２００（第１２図）がパラメー タ及びも変数の何れも表現していない場合、即ちエクスターナルモデル構造体１ ２００が呼び出される関数の戻り値項目を表現している場合には、処理はテスト ステップ４６１６からテストステップ４６１２に進む。また、処理はステップ４ ６１６（第４６図）の他ステップ４６１４からもテストステップ４６１６に進み 得る。テストステップ４６１６において、実行エンジン８０２（第８図）は、エ クスターナルモデル構造体１２００（第１２図）によって表現されるエクスター ナルを表現する項目が定義されているか否かを判定する。項目が定義されている のは、（ｉ）ステップ４６１０においてエクスターナルモデル構造体１２００に よって表現されるパラメータの値が定義され、既知の値に評価されて、かつ処理 がステップ４６１６（第４６図）を通って進む場合、または（ｉｉ）ステップ４ ６１４においてエクスターナルモデル構造体１２００（第１２図）によって表現 される変数が初期化され、処理がステップ４６１４（第４６図）を通って進む場 合である。 エクスターナルモデル構造体１２００（第１２図）よって表現されるエクスタ ーナルを表現する項目が定義されない場合には、処理はテストステップ４６１６ （第４６図）から後に説明するテストステップ４６２４に進む。逆に、このよう なアイテムが定義される場合には、処理はテストステップ４６１６からループス テップ４６１８に進む。 ループステップ４６１８及びＮＥＸＴステップ４６２２はループを形成し、こ のループの中でエクスターナルモデル構造体１２００のフィー ルド“ｏｐｅｒａｔｉｏｎｓ”１２１４（第１２図）に格納された各演算が処理 される。上述のように、フィールド“ｏｐｅｒａｔｉｏｎｓ”１２１４に格納さ れた演算の数は、フィールド“ｎｕｍ ｏｐｅｒａｔｉｏｎｓ”１２１２に記録 される。フィールド”ｏｐｅｒａｔｉｏｎｓ”１２１４に格納された各演算に対 して処理はループステップ４６１８（第４６図）からステップ４６２０に進み、 ここでステップ２９０６（第２９図）に関連して上述したのと同じ方法で、エク スターナルモデル構造体１２００（第１２図）によって表現されるエクスターナ ルに演算が施される。エクスターナルに演算を施すことによって何らかのエラー が検出されたときには、それが上述の方法と同様にプログラミングエラーとして ユーザに通知される。ステップ４６２０（第４６図）から、処理はＮＥＸＴステ ップ４６２２を通してループステップ４６１８に進み、ここでフィールド“ｏｐ ｅｒａｔｉｏｎｓ”１２１４（第１２図）に格納された次の演算があれば、それ が処理される。フィールド“ｏｐｅｒａｔｉｏｎｓ”１２１４に格納された全て の演算がループステップ４６１８（第４６図）及びＮＥＸＴステップ４６２２に よって定義されたループに従ってひとたび処理されると、処理はテストステップ ４６２４に進む。 テストステップ４６２４において、実行エンジン８０２（第８図）は、エクス ターナルモデル構造体１２００（第１２図）が、エクスターナルモデル構造体１ ２００によって表現されるエクスターナルの代わりに新たなリソースが生成され ることを指定するか否かを判定する。実行エンジン８０２（第８図）は、フィー ルド“ｎｅｗ ｒｅｓｏｕｒｃｅｓ”１２１８（第１２図）とブール値“ｔｒｕ ｅ”とを比較することによってこの判定を行う。フィールド“ｎｅｗ ｒｅｓｏ ｕｒｃｅｓ”１２１８が“ｆａｌｓｅ”である場合には、処理はテストステップ ４６２４（第 ４６図）からＮＥＸＴステップ４６３０を通って、ループステップ４６０６に進 み、ここで次のエクスターナルが、上述のようにループステップ４６０６及びＮ ＥＸＴステップ４６３０により定義されるループに従って処理される。逆に、フ ィールド“ｎｅｗ ｒｅｓｏｕｒｃｅｓ”１２１８（第１２図）が“ｔｒｕｅ” である場合には、処理はテストステップ４６２４（第４６図）からステップ４６ ２６に進む。 ステップ４６２６において、実行エンジン８０２（第８図）は、（ｉ）項目構 造体、即ち項目構造体２７００（第２７図）及びリソース状態構造体、即ちリソ ース状態構造体３１００（第３１図）を生成してメモリ１０４（第１図）に格納 し、（ｉｉ）リソース状態構造体３１００（第３１図）を指定するポインタをフ ィールド“ｒｅｓｏｕｒｃｅ”２７０２に格納して、リソース状態構造体３１０ ０と項目構造体２７００（第２７図）とを関連付けることによって、新たなリソ ースを生成する。処理はステップ４６２６（第４６図）からステップ４６２８に 進み、ここで実行エンジン８０２（第８図）が、新たな項目と、エクスターナル モデル構造体１２００（第１２図）によって表現されるエクスターナルとを連係 させる。エクスターナルリスト構造体１４１４（第１５図）がそのエクスターナ ルを表現している場合には、フィールド“ｆｉｒｓｔ ｄｅｃｌ”１５０２（第 １５図）が指定する宣言構造体１５０６のフィールド“ｉｔｅｍ”１６０８（第 １６図）に、項目構造体２７００（第２７図）を指定するポインタを格納するこ とによって、その項目がそのエクスターナルに関連付けられる。 エクスターナルが呼び出される関数の戻り値項目である場合には、論理流れ図 ３３５２（第４６図）の始めにＮＵＬＬに設定されていた結果レコードが新たな 項目に設定される。エクスターナルモデル構造体１２００のフィールド“ｔｙｐ ｅ”１２０４（第１２図）がそれを示してい る場合には、そのエクスターナルは、呼び出される関数の戻り値項目である。エ クスターナルが呼び出される関数の戻り値項目でない場合には、そのエクスター ナルを表現する宣言構造体１５０６のフィールド“ｉｔｅｍ”１６０８（第１６ 図）に新たな項目が形成される。 ステップ４６２８（第４６図）から、処理はＮＥＸＴステップ４６３０を通っ てループステップ４６０６に進み、ここで上述のように次のエクスターナルが処 理される。呼び出される関数を表現する関数モデル構造体１１００のフィールド “ｆｉｒｓｔ ｅｘｔｅｒｎａｌ”１１０４（第１１図）及び“ｌａｓｔ ｅｘ ｔｅｒｎａｌ”１１０６によって指定されるエクスターナル構造体のシングルリ ンクトリストにおけるエクスターナル構造体によって表現されるエクスターナル の全てがひとたび処理されると、処理はループステップ４６０６（第４６図）か らステップ４６３２に進む。ステップ４６３２において、実行エンジン８０２（ 第８図）は、呼び出される関数の実行のエミュレーションにより評価して得られ た項目として、結果レコードを生成する。ステップ４６２８（第４６図）に関連 して上述したように、この結果レコードはＮＵＬＬ値に初期化され、戻り値項目 の代わりに新たなリソースが生成された場合には、戻り値項目の値に設定される 。 ステップ４６３２の終了後、処理は論理流れ図３３５２に従って、即ちステッ プ３３５２（第３３Ｃ図）に従って終了する。従って、呼び出される関数の挙動 を表現するモデルを用いることによって、サブジェクト関数内に呼び出される関 数に対する呼出しを評価して、呼び出される関数の実行のリソース及びエクスタ ーナルに対する評価を解析することができる。メモリの集群 Ｃ言語に特有なことの１つは、あるメモリを、連続して割り当てられ た配列として取り扱うことができるという点である。Ｃ言語においては、以下の 型のメモリは、そのメモリが連続したブロックとして割り当てられたメモリであ るかのようにアクセスすることができる。そのようなメモリの型とは、（ｉ）命 令“ｓｔｒｕｃｔ”若しくは“ａｒｒａｙ”を用いて定義された変数若しくはパ ラメータの何れかのデータ、即ち複合データ構造体若しくは配列、（ｉｉ）関数 にパラメータとして渡される任意のポインタ、（ｉｉｉ）Ｃ言語において定義さ れている関数ｃａｌｌｏｃ () 若しくは関数ｍａｌｌｏｃ () の実行により割り 当てられるメモリである。本発明のここに開示する実施例では、連続して割り当 てられるメモリをモデル化するためにメモリの集群（bunch）を用いている。 項目構造体は集群、即ち項目構造体の連続的な配列に割り当てられる。１つの 整数、若しくは浮動小数点型変数の宣言を表現する項目構造体の場合についての み述べると、この集群は１つの項目構造体を含む。複合型の変数、即ち“ｓｔｒ ｕｃｔ”型及び配列の変数を表現する項目構造体の集群は、多重項目構造体によ って表現され、その項目構造体のそれぞれは、４バイトの配列若しくは複合デー タの変数である。 連続して割り当てられた項目構造体を有する連続して割り当てられたメモリを 表現することにより、いくつかのイリーガルな配列参照の検出が可能となる。例 えば、連続して割り当てられた項目構造体の集群の範囲内の項目構造体に対する 参照は、その集群によって表現される配列のイリーガルな指標（index）に対応 する。更に、項目構造体を集群に形成することにより、上述のようなメモリのリ ークの検出も単純化される。例えば、集群とされた何らかの項目構造体が関数の エクスターナルによって到達可能な場合は、集群における各項目構造体にも、そ の関数のエクスターナルが到達可能である。 上述のように、項目構造体２７００（第２７図）は、フィールド“ｆｉｒｓｔ ｉｎ ｂｕｎｃｈ”２７０８、フィールド“ｓｉｚｅ ｏｆ ｂｕｎｃｈ”２ ７１０、フィールド“ｈｅａｄ ｉｎ ｂｕｎｃｈ”２７１６、及びフィールド “ｋｎｏｗｎ ｂｕｎｃｈ ｓｉｚｅ”２７１８を含む。フィールド“ｆｉｒｓ ｔ ｉｎ ｂｕｎｃｈ”２７０８は、項目構造体２７００を含む項目構造体の集 群における第１の項目構造体を指定するポインタである。項目構造体２７００が １つの集群における第１の項目構造体である場合には、フィールド“ｆｉｒｓｔ ｉｎ ｂｕｎｃｈ”２７０８が項目構造体２７００を指定する。フィールド“ ｓｉｚｅ ｏｆ ｂｕｎｃｈ”２７１０は、項目構造体２７００を含む集群にお ける項目構造体の数を示す。一実施例においては、フィールド”ｓｉｚｅ ｏｆ ｂｕｎｃｈ”２７１０が、所与の集群における第１の項目構造体においてのみ 、そのように定義されている。 フィールド“ｈｅａｄ ｉｎ ｂｕｎｃｈ”２７１６は、項目構造体２７００ が、その項目構造体２７００を含む集群における第１項目構造体であるか否かを 示すフラグである。フィールド“ｋｎｏｗｎ ｂｕｎｃｈ ｓｉｚｅ”２７１８ は、項目構造体２７００を含む集群が既知のサイズを有するか否かを示すフラグ である。集群が未知のサイズを有するのは、例えば、（ｉ）その集群が動的に割 り当てられる、即ち関数ｍａｌｌｏｃ () を呼び出すことによって割り当てられ 、かつ実行エンジン８０２（第８図）が、要求されるメモリの量を計算するのに 十分な情報を有していないとき、（ｉｉ）その集群がサブジェクト関数に引き渡 される場合、若しくは（ｉｉｉ）その集群がその集群の各項目の追跡が実際には 無理であるようなサイズを有する場合である。フィールド“ｋｎｏｗｎ ｂｕｎ ｃｈ ｓｉｚｅ”２７１８によって示されることにより集群が未知のサイズを有 している場合には、実行エンジン８０２（第 ８図）は、その集群の範囲を逸脱する違反のチェックは行わない。 付録Ａ（Ａppendix Ａ）のコンピュータプログラムは、一実施例として、米国 カリフォルニア州マウンテンビュー（mountain view）のサンマイクロシステム ズ社（Ｓun Ｍicrosystems）から入手可能なＳｕｎ Ｓｐａｒｃｓｔａｔｉｏｎ （登録商標）コンピュータシステムのようなワークステーションに備えられてい る、ＵＮＩＸオペレーティングシステムＳｕｎＯＳ４．１．３、コンパイラ、及 びリンカーを用いてコンパイルされ、リンクされた。第２実施例では、付録Ａの コンピュータプログラムは、マイクロソフト社のＶｉｓｕａｌ Ｃ＋＋１．５コ ンパイラを用いてコンパイルされ、同社のＶｉｓｕａｌ Ｃ＋＋リンカーを用い てリンクされた。これらのコンパイラ及びリンカーは、米国ワシントン州レッド モンド（Ｒedmond）のマイクロソフト社から発売されており、同様に同社から発 売されているＭＳ ＤＯＳ６．２オペレーティングシステム、Ｍｉｃｒｏｓｏｆ ｔ Ｗｉｎｄｏｗｓ（登録商標）３．１を用いているパーソナルコンピュータ上 で用いられる。使用できるパーソナルコンピュータには、米国カリフォルニア州 サンフランシスコのＡｔｍａｎ社製のＡｒｔ４０００Ｓなどがある。付録Ａのコ ンピュータプログラムが適合する特定のコンピュータ言語や、付録Ａのコンピュ ータプログラムにより定義されたコンピュータプロセスが実行されるコンピュー タシステムは、本発明における重要な側面ではない。当業者は、本明細書の記載 内容を参照することにより、異なるコンピュータ言語及び／若しくは異なるコン ピュータシステムを用いて本発明を実現できよう。 付録Ａには複数のソースコードファイルが含まれており、これには本発明の別 の実施例に基づき複数の関数及びデータ構造を定義するソースコードファイル“ ｒｅａｄｉｎ．ｃ”の２つの別の実施例が含まれている。ソースコードファイル “ｒｅａｄｉｎ．ｃ”の第１実施例は、付録 Ａのフレーム６４〜７４に現れており、ソースコードファイル“ｒｅａｄｉｎ． ｃ”の第２実施例は、付録Ａのフレーム７７〜８７に現れている。ソースコード ファイルの実施例の一方のみが付録Ａの残りの部分とリンクされて、本発明の原 理に基づくリソースチェッカーを形成するということは理解されよう。 以上の記述は本発明を説明するためのものであり、本発明をこれに限定するも のではない。例えば、ここに開示した実施例はＣ言語における関数を分析してい るが、本発明の原理は、以上の記述の内容に限定されることなく、他のコンピュ ータ命令プロトコルにも適用され得る。更に、本発明を実現したコンピュータプ ログラムを何らかの媒体に格納して提供することも可能である。本発明の範囲は 、以下の請求の範囲によってのみ限定される。

【手続補正書】特許法第１８４条の８第１項 【提出日】１９９５年９月２０日 【補正内容】 第２５図は、第２４図の論理流れ図中の一過程の論理流れ図である。 第２６図は、第２４図の論理流れ図に基づくコンピュータプログラムコンポー ネントの繰返し評価の一回分の論理流れ図である。 第２７図は、本発明の実施例に基づく項目構造体（item structure）のブロッ ク図である。 第２８図は、本発明の実施例に基づくステートメントの解析の論理流れ図であ る。 第２９図は、本発明の実施例に基づく式の評価の論理流れ図である。 第３０図は、本発明の実施例に基づくエクスターナル構造体のブロック図であ る。 第３１図は、本発明の実施例に基づくリソース構造体（resource structure） のブロック図である。 第３２図は、本発明の実施例に基づく項目への演算の適用の論理流れ図である 。 第３３Ａ図、第３３Ｂ図、第３３Ｃ、第３３Ｄ、及び第３３Ｅ図は、本発明の 実施例に基づく演算子の処理の論理流れ図である。 第３４図は、本発明の実施例に基づく宣言の処理の論理流れ図である。 第３５図は、本発明の実施例に基づく“ｉｆ”ステートメントの処理の論理流 れ図である。 第３６図は、本発明に基づく論理演算子の処理の論理流れ図である。 第３７図は、第３６図の論理流れ図の一過程の処理の論理流れ図である。 第３８図は、第３６図の論理流れ図の別の過程の処理の論理流れ図である。 第３９図は、本発明の実施例に基づく“ｒｅｔｕｒｎ”ステートメントの処理 の論理流れ図である。 子によって指定された処理が実行される。上述のように、式は、動的検査エンジ ン７０６（第７図）内に於いて式構造体２２００（第２２図）のような式構造体 によって表現される。式構造体２２００のフィールド“ｋｉｎｄ”２２０２はそ の式の演算子の種類を指定し、またフィールド“ｏｐｅｒａｎｄｓ”２２１０は その演算子の演算が施されるオペランドを含む。 このサブジェクト関数の解析は、コンピュータプロセス内に於けるそのサブジ ェクト関数の実行の文脈内で行われるので、このサブジェクト関数のエクスター ナルの初期値は未知である。従って、このサブジェクト関数に於ける式は、既知 の値に評価しなくてもよい。従って、ステップ２９０２（第２９図）での実行エ ンジン８０２（第８図）による式の評価により、式の評価により既知の若しくは 部分的に既知の値が生成される場合には項目が生成され、そうでない場合にはＮ ＵＬＬが生成される。後に詳述するように、項目は、「部分的に既知」の値を有 し得る。例えば、項目が０でない値を有していることは知ることはできるが、項 目の正確な値はまだ知ることができず、この場合その項目の値は「部分的に既知 」であるという。ステップ２９０２は論理流れ図２９０２（第３３ａ図、第３３ ｂ図、第３３ｃ図、第３３ｄ図、及び第３３ｅ図）に詳しく示されており、後に 詳細に説明する。 ステップ２９０２（第２９図）から、処理はテストステップ２９０４に進み、 ここで実行エンジン８０２（第８図）が、式の評価によりＮＵＬＬでなく項目が 生成されたか否か、及びステートマシン８０４によりその項目に演算が施される か否かを判定する。その式の評価により項目が生成されない場合、若しくはその 項目に演算が施されない場合には、処理はテストステップ２９０４（第２９図） から後に説明するステップ２９０８に進む。逆に、その式の評価により項目が生 成されその項目に 連するリソースまたはエクスターナルに演算が施され、何らかのエラーが検出さ れてそれがユーザに通知される。ステップ２９０６から、処理はステップ２９０ ８に進む。また、式の評価により生成された項目が存在しない場合、若しくは上 述のようにその式に対して施される演算が無い場合は、処理はテストステップ２ ９０４から直接ステップ２９０８に進む。ステップ２９０８においては、実行エ ンジン８０２は、式、即ち、サブジェクトステートメントを含んでおり、更に、 項目が生成された場合にはその項目を、生成されなかった場合には数値がＮＵＬ Ｌである項目を含んでいる。詳述すると、実行エンジン８０２はサブジェクトス テートメントを表現する式構造体２２００のフィールド“ｉｔｅｍ”２２０６（ 第２２図）に、その項目を指定するポインタを格納する。従って、後に行われる その式の評価においては、単に、その項目がフィールド“ｉｔｅｍ”２２０６が 指定する部位に戻されるだけとなり、これによって冗長な処理が回避される。ス テップ２９０８（第２９図）の後、処理は論理流れ図２９００に従って終了する 。定数 上述のように、論理流れ図２９０２（第３３Ａ図〜第３３Ｅ図）に詳細に示さ れているステップ２９０２（第２９図）においては、実行エンジン８０２（第８ 図）は、式における演算子によって規定されている通りに式を処理する。実行エ ンジン８０２は、演算の型に応じてその式を処理する。テストステップ３３０１ （第３３Ａ図）においては、論理流れ図２９０２に従って処理が開始されるが、 ここでは実行エンジン８０２（第８図）が、その式が演算子は含んでいないが、 代わりに定数を含んでいるか否かを判定する。式構造体２２００（第２２図）が サブジェクトステートメントの式を表現している場合は、実行エンジン８０２（ 第８図）は、式構造体２２００のフィールド“ｋｉｎｄ”２２０２（第２ ０２（第２９図）に従って終了する。単項演算子 上述のように、この式の演算子が関係演算子でない場合には、処理はテストス テップ３３０９（第３３Ａ図）からテストステップ３３１３に進む。テストステ ップ３３１３においては、実行エンジン８０２（第８図）が、式の演算子が単項 演算子であるか否かを、その式を表現する式構造体のフィールド“ｋｉｎｄ”２ ２０２（第２２図）と、単項演算子を示すデータとを比較することによって判定 する。単項演算子は、ただ１つのオペランドを有する演算を特定する演算子であ る。例えば、式“−ａ”は、ただ１つのオペランド“ａ”と、オペランド“ａ” に対して数値を負にする演算を特定する単項演算子“−”とを有する。式が１つ のオペランドを有し、かつ式構造体２２００によって表現されている場合には、 その式のただ１つのオペランドが、フィールド“ｏｐｅｒａｎｄｓ”２２１０の 第１の要素である式構造体によって表現される。 式の演算子が単項演算子でない場合には、処理はテストステップ３３１３（第 ３３Ｂ図）から、後に説明するテストステップ３３１３（第３３Ｂ図）に進む。 逆に、式の演算子が単項演算子である場合には、処理はテストステップ３３１３ （第３３Ｂ図）からステップ３３１４に進む。ステップ３３１４においては、実 行エンジン８０２（第８図）が、論理流れ図２９００（第２９図）に従って式の オペランドを式として評価するとともに、演算ｃを適用する。演算ｃは、式のオ ペランドに適用されるが、これはこのオペランドが計算において使用されるから である。このような計算において式のオペランドが不適切に使用されている場合 には、上述のように、演算を適用することによりエラーメッセージが生成される 。 処理はステップ３３１４（第３３Ｂ図）からステップ３３１５に進み、 ここでは式の単項演算子が式の評価のために用いられる。ステップ３３１５は上 述のステップ３３０８に類似している。ステップ３３１５の終了後、処理は論理 流れ図２９０２、即ちステップ２９０２（第２９図）に従って終了する。特定の演算子による処理 上述のように、式の演算子が単項演算子でない場合には、処理はテストステッ プ３３１３（第３３Ｂ図）からテストステップ３３１７（第３３Ｂ図）に進む。 更に上述したように、論理流れ図２９０２における上述のステップでは、式の演 算子の型に従って式の処理が行われる。テストステップ３１７及びそれに続くス テップにおいて、式の演算子の型がテストステップ３３０１（第３３Ａ図）、３ ３０３、３３０５、３３０９及び３３１３で判定される演算子の型の中に入って いない場合に、実行エンジン８０２（第８図）が、式の特定の演算子に従って式 の処理を行う。インクリメント演算子またはデクリメント演算子 ステップ３３１７（第３３Ｂ図）においては、実行エンジン８０２（第８図） が、式の演算子とインクリメント演算子及びデクリメント演算子とを比較する。 つまり、式構造体２２００（第２２図）がその式を表現している場合、実行エン ジン８０２は、フィールド”ｋｉｎｄ”２２０２（第２２図）と、インクリメン ト演算子若しくはデクリメント演算子を指定するデータとを比較する。インクリ メント演算子若しくはデクリメント演算子は、１つのオペランドに対してそのオ ペランドを１づつ増減させる演算を施す。その式の演算子がインクリメント演算 子でもデクリメント演算子でもない場合には、処理は、後に説明するテストステ ップ３３２０（第３３Ｂ図）に進む。逆に、式の演算子がインクリメント演算子 またはデクリメント演算子である場合には、処理はテストステッ ンマ（“，”）は、２つのオペランド、即ち式のｌｈｓ及びｒｈｓに対して演算 を施し、演算結果としてｒｈｓを評価した値を有する項目を生成する。つまり、 ２つのオペランドは個別に評価され、式のｒｈｓを評価した値が式の値になるの である。 式の演算子が複合演算子でない場合には、処理はテストステップ３３２７（第 ３３Ｃ図）からテストステップ３３３０に進む。逆に、式の演算子が複合演算子 である場合には、処理はテストステップ３３２７からステップ３３２８に進む。 ステップ３３２８においては、実行エンジン８０２（第８図）が論理流れ図２ ９００（第２９図）に従って式のｌｈｓをその式として評価し、また演算の適用 は行わない。ステップ３３２８（第３３Ｃ図）から処理はステップ３３２９に進 み、ここでは実行エンジン８０２（第８図）が論理流れ図２９００（第２９図） に従って式のｒｈｓを評価する。論理流れ図２９００に従って、複合演算子を含 む式を評価する場合に施される演算は、ステップ３３２９（第３３Ｃ図）におい てｒｈｓを評価するときにｒｈｓに施される演算と類似したものである。式のｒ ｈｓの評価によって生成される項目は、その式そのものの項目として戻される。 ステップ３３２９（第３３Ｃ図）の終了後、処理は論理流れ図２９０２に従って 、即ちステップ２９０２（第２９図）に従って終了する。間接演算子 上述のように、式の演算子が複合演算子でない場合には、処理はテストステッ プ３３２７（第３３Ｃ図）からテストステップ３３３０に進む。テストステップ ３３３０においては、実行エンジン８０２（第８図）がその式の演算子が間接演 算子（indirection operator）であるか否かを、その式を表す式構造体のフィー ルド”ｋｉｎｄ”２２０２（第２２図）と間接演算子を指定するデータとを比較 することによって判定する。Ｃ 言語においては、間接演算子（即ち“＊”）は１つのオペランドに対して演算を 施し、演算結果としてメモリ、即ちメモリ１０４（第１図）内のそのオペランド によって指定されたアドレスに格納された値を有する項目を生成する。例えば、 式“＊ａ”は、メモリ内のアドレス“ａ”に格納された値を有する項目に対して 評価を行う。間接演算子は、配列の要素を参照するためにも使用され得る。例え ば、宣言“ｉｎｔ ａｒｒａｙ[１０]”によって規定された配列の第２要素は、 “ａｒｒａｙ[１]”または“＊（ａｒｒａｙ＋１）”の何れかによって特定され 得る。後者の式はその配列の要素のサイズのアレイの始まる点を０としたときの 相対位置（オフセット）１に格納された値、即ち配列の第２要素の値を参照する ものである。 その式の演算子が間接演算子でない場合には、処理はテストステップ３３３０ （第３３Ｃ図）からテストステップ３３３５に進む。逆に、その式の演算子が間 接演算子である場合には、処理はテストステップ３３３０からテストステップ３ ３３１に進む。 テストステップ３３３１においては、実行エンジン８０２（第８図）がそのオ ペランドが配列であるか否かを判定する。式構造体２２２０（第２２図）がその オペランドを表現している場合には、フィールド“ｔｙｐｅ”２２０４（第２２ 図）がそのオペランドの型を指定する型構造体を指定する。例えば、型構造体１ ６１２（第１７図）が式構造体２２２０のフィールド“ｔｙｐｅ”２２０４（第 ２２図）によって指定されている場合には、実行エンジン８０２（第８図）がそ のオペランドが配列であるか否かを、フィールド“ｋｉｎｄ”１７０２（第１７ 図）と配列を指定するデータとを比較することによって判定する。 そのオペランドが配列である場合には、処理はテストステップ３３３１（第３ ３Ｃ図）からステップ３３３２に進み、ここで実行エンジン８ ０２（第８図）が、論理流れ図２９００（第２９図）に従って、そのオペランド をその式として評価し、かつ演算は適用しないが、その演算子を、配列の間接ア ドレス指定手段として、即ち上述の“＊（ａｒｒａｙ＋１）”の型式の配列の１ つの要素の参照要素として取り扱う。逆に、オペランドが配列でない場合には、 処理はテストステップ３３３１（第３３Ｃ図）からステップ３３３３に進み、こ こでは実行エンジン８０２（第８図）が、論理流れ図２９００（第２９図）に従 ってその式のオペランドを評価するとともに、演算ｉを適用し、かつその演算子 を間接アドレスを指定するポインタ、即ち上述の式“＊ａ”のためのものとして 取り扱う。 処理はステップ３３３２（第３３Ｃ図）またはステップ３３３３の何れかから 、ステップ３３３４に進み、ここでは実行エンジン８０２（第８図）が、そのオ ペランドをデリファレンスする。オペランドのデリファレンスにおいて、その式 の評価により、オペランドが指定する項目が生成される。オペランドが項目を指 定していない場合には、式はＮＵＬＬに評価される。ステップ３３３４（第３３ Ｃ図）の終了後、論理流れ図２９０２に従って、即ちステップ２９０２（第２９ 図）に従って処理は終了する。コンポーネント参照演算子 上述のように、式の演算子が間接演算子でない場合には、処理はテストステッ プ３３３０（第３３Ｃ図）からテストステップ３３３５に進む。テストステップ ３３３５においては、実行エンジン８０２（第８図）が、その式の演算子がコン ポーネント参照演算子であるか否かを、その式を表現する式構造体のフィールド “ｋｉｎｄ”２２０２（第２２図）と、コンポーネント参照演算子を指定するデ ータとを比較することによって判定する。Ｃ言語においては、コンポーネント参 照演算子（即ち、“．” または“−＞”）は、２つのオペランド、即ち式のｌｈｓ及びｒｈｓに対して演 算を施し、演算結果としてｒｈｓによって特定されたｌｈｓのフィールド項目を 生成する。例えば、宣言“ｓｔｒｕｃｔ｛ｉｎｔ ａ；ｃｈａｒ ＊ｂ｝ｃ，＊ ｄ”が宣言しているのは、項目“ｃ”及び第２項目に対するポインタ“ｄ”であ って、それぞれが、データの型“ｉｎｔ”、即ち整数の第１フィールド項目“ａ ”及びデータの型が”ｃｈａｒ”、即ち文字であるデータを指定する第２フィー ルド項目“ｂ”を有することを表している。式“ｃ．ａ”は、項目“ｃ”の整数 フィールド項目に評価される。同様に、式“ｄ−＞ａ”は、ポインタ“ｄ”が指 定する項目の整数フィールド項目に評価される。 式の演算子がコンポーネント参照演算子でない場合には、処理はテストステッ プ３３３５（第３３Ｃ図）からテストステップ３３３８（第３３Ｄ図）に進む。 逆に式の演算子がコンポーネント参照演算子である場合には、処理はテストステ ップ３３３５（第３３Ｃ図）からステップ３３３６に進む。 ステップ３３３６においては、実行エンジン８０２（第８図）が論理流れ図２ ９００（第２９図）に従って式のｌｈｓを評価し、また演算は施されない。ステ ップ３３３６（第３３Ｃ図）から、処理はステップ３３３７に進み、ここで実行 エンジン８０２（第８図）が、式のｒｈｓによって指定されるフィールドを検索 する。ステップ３３３７の終了後、処理は論理流れ図２９０２に従って、即ちス テップ２９０２（第２９図）に従って終了する。配列参照演算子 上述のように、式の演算子がコンポーネント演算子でない場合には、処理はテ ストステップ３３３５（第３３Ｃ図）からテストステップ３３３８（第３３Ｄ図 ）に進む。テストステップ３３３８においては、実行 エンジン８０２（第８図）が式の演算子が配列参照演算子であるか否かを、その 式を表現する式構造体のフィールド“ｋｉｎｄ”２２０２（第２２図）と、配列 参照演算子を指定するデータとの比較を行うことによって判定する。Ｃ言語にお いては、配列参照演算子（即ち、“ [] ”）は２つのオペランド、即ちその式の ｌｈｓ及びｒｈｓに対して演算を施し、演算結果として、ｒｈｓにより特定され るｌｈｓの配列の要素を生成する。例えば、宣言“ｉｎｔ ａｒｒａｙ［１０］ ”が宣言するのは１０個の整数の配列である。式“ａｒｒａｙ［ｂ］”は、配列 “ａｒｒａｙ”の、項目“ｂ”によって指定される位置に存在する整数の要素に 評価される。項目“ｂ”、即ちｒｈｓは指標（index）と称されることもある。 Ｃ言語においては、配列参照演算子は、非配列ポインタからのオフセットを参 照するためにも使用されうる。例えば、“ｄａｔｕｍ”が型が“ｉｎｔ”である 変数である場合、式“ｄａｔｕｍ［２］”は、メモリ１０４（第１図）の、変数 “ｄａｔｕｍ”を表現する項目から２メモリ位置だけオフセットした位置に格納 されたデータに評価される。２メモリ位置は、変数“ｄａｔｕｍ”の型、即ちデ ータの型“ｉｎｔ”の変数２つ分の長さに等しい。上述のように、Ｃ言語の文脈 においては、“ａｒｒａｙ［ｉ］”及び“＊（ａｒｒａｙ＋ｉ）”は、等価な式 である（Ｃスタンダードのセクション６．３、２．１参照）。 その式の演算子が配列参照演算子でない場合は、処理はテストステップ３３３ ８（第３３Ｄ図）からテストステップ３３４４に進む。逆に、この式の演算子が 配列参照演算子である場合には、処理はテストステップ３３３８からステップ３ ３３９に進む。 ステップ３３３９において、実行エンジン（第８図）は、論理流れ図２９００ （第２９図）に従ってその式の指標を評価し、また演算ｃを施 す。演算ｃを施すのは、この指標は計算に使用されるからである。ステップ３３ ３９（第３３Ｄ図）から、処理はテストステップ３３４０に進み、ここで実行エ ンジン８０２（第８図）が、ｌｈｓが配列であるか否かを、テストステップ３３ ３１（第３３Ｃ図）に関連して前に説明した方法で判定する。ｌｈｓが配列であ る場合には、処理はテストステップ３３４０（第３３Ｄ図）からステップ３３４ １に進み、ここで実行エンジン８０２（第８図）が、論理流れ図２９００（第２ 図）に従ってその式のｒｈｓを指標として評価する。このとき演算は施されない 。逆に、ｌｈｓが配列でない場合には、処理はテストステップ３３４０（第３３ Ｄ図）からステップ３３４２に進み、ここで実行エンジン８０２（第８図）が論 理流れ図２９００（第２９図）に従ってその式のｒｈｓをポインタとして評価し 、かつ演算ｉを施す。 処理はステップ３３４１（第３３Ｄ図）若しくはステップ３３４２の何れかか ら、ステップ３３４３に進み、ここで実行エンジン８０２（第８図）が、ｌｈｓ によって特定された配列の、ｒｈｓによって指定された要素を検索する。ステッ プ３３４３（第３３Ｄ図）の終了後、処理は論理流れ図２９０２に従って、即ち ステップ２９０２（第２９図）に従って終了する。アドレス演算子 上述のように、その式の演算子が配列演算子でない場合には、処理はテストス テップ３３３８（第３３Ｄ図）からテストステップ３３４４に進む。テストステ ップ３３４４においては、実行エンジン８０２（第８図）が、その式の演算子が アドレス演算子であるか否かを、その式を表現する式構造体のフィールド“ｋｉ ｎｄ”２２０２と、アドレス演算子を指定するデータとを比較することによって 判定する。Ｃ言語においては、アドレス演算子（即ち“＆”）は、１つのオペラ ンドに対して演算 を施し、演算結果としてオペランドのアドレスがその値である項目を生成する。 例えば、式“＆ａ”は、メモリ、即ちメモリ１０４内の、項目“ａ”が格納され ているアドレスをその値とする項目に評価される。 その式の演算子がアドレス演算子でない場合には、処理はテストステップ３３ ４４（第３３Ｄ図）からテストステップ３３４７に進む。逆に、その式の演算子 がアドレス演算子である場合には、処理はテストステップ３３４４からステップ ３３４５に進む。 ステップ３３４５においては、実行エンジン８０２（第８図）が、論理流れ図 ２９００（第２９図）に従ってオペランドの評価を行い、このとき他の演算は施 されない。ステップ３３４５（第３３Ｄ図）から、処理はテストステップ３３４ ６に進み、ここでこのアドレス演算子はその式を評価するのに使用される。つま り、オペランドのアドレスが決定されるのである。ステップ３３４６は、前に説 明したステップ３３０８（第３３Ａ図）に類似している。ステップ３３４６（第 ３３Ｄ図）が終了した後、処理は論理流れ図２９０２に従って、即ちステップ２ ９０２（第２９図）に従って終了する。関数の呼出し 上述のように、式の演算子がアドレス演算子でない場合には、処理はテストス テップ３３４４（第３３Ｄ図）からテストステップ３３４７に進む。テストステ ップ３３４７においては、実行エンジン８０２（第８図）が、その式の演算子が 関数の呼出しであるか否かを、その式を表現する式構造体のフィールド“ｋｉｎ ｄ”２２０２（第２２図）と、関数の呼出しを指定するデータとを比較すること によって判定する。Ｃ言語においては、関数演算子（即ち“ () ”）は、関数の 呼出しを意味する。関数の呼出しは、その関数の戻り値項目（returned item） に評価される。例えば、式“ａｂｃ () ”は、識別子が“ａｂｃ”である関数の 実行の 呼出しを行う。同様に、式“ｘｙｚ（ｄ，ｅ，ｆ）”は、その識別子が“ｘｙｚ ”である、パラメータとして項目ｄ，ｅ，及びｆが与えられている関数を呼び出 す。 式の演算子が関数の呼出しでない場合には、処理はテストステップ３３４７（ 第３３Ｅ図）からテストステップ３３５３に進む。逆に、式の演算子が関数の呼 出しである場合には、処理はテストステップ３３４７からループステップ３３４ ８に進む。 ループステップ３３４８、ステップ３３４９、及びＮＥＸＴステップ３３５０ は、各パラメータの評価が行われるループを形成する。ステップ３３４９におい て、実行エンジン８０２（第８図）は、論理流れ図２９００（第２９図）に従っ てパラメータの評価を行い、また演算は施さない。式構造体２２００（第２２図 ）がその式を表現している場合、即ち関数の呼出しを表現している場合には、（ ｉ）フィールド“ｎｕｍ ｏｐｅｒａｎｄｓ”２２０８が呼び出された関数のパ ラメータの数をオペランドの数として特定し、（ｉｉ）フィールド“ｏｐｅｒａ ｎｄｓ”２２１０は式構造体の配列であり、この式構造体の各要素は呼び出され た関数のパラメータを表現する式構造体である。各パラメータの評価は、フィー ルド“ｏｐｅｒａｎｄｓ”２２１０の各要素を評価することによって行われる。 呼び出された関数のパラメータを表現する項目の配列は、ループステップ３３４ ８、ステップ３３４９、及びＮＥＸＴステップ３３５０によって形成されたルー プにおいて構成され、後に（第４６図に関連して）詳しく説明するように、ステ ップ３３５２において呼び出された関数の実行をエミュレートするのに用いられ る。 ひとたび呼出される関数の各パラメータが評価されると、処理はループステッ プ３３４８（第３３Ｅ図）からステップ３３５１に進む。ステップ３３５１にお いては、実行エンジン８０２（第８図）が、呼び出さ れる関数のエクスターナルにおける実行の効果を表現する関数モデル構造体を抽 出する。関数モデル構造体は、第１１図〜第１３図に関連して以前に説明してあ る。ステップ３３５１（第３３Ｅ図）から、処理はステップ３３５２に進み、こ こで実行エンジン８０２（第８図）が、呼び出される関数の実行のエミュレート については後に詳しく説明する。ここで簡単に説明すると呼び出される関数のエ ミュレートは、上述の関数モデル（３）、（４）、及び（５）から形成される関 数モデル構造体のような、関数モデル構造体において特定された演算を適用する ことによって行われる。この呼び出された関数に対応する関数モデル構造体は、 呼び出される関数のエクスターナルにおける実行の効果を表現する演算を特定す る。ステップ３３５２（第３３Ｅ図）の終了後、処理は、論理流れ図２９０２に 従って、即ちステップ２９０２（第２９図）に従って終了する。代入 上述のように、その式の演算子が関数の呼出しでない場合には、処理はテスト ステップ３３４７（第３３Ｅ図）からテストステップ３３５３に進む。テストス テップ３３５３においては、実行エンジン８０２（第８図）が、その関数の演算 子が代入演算子であるか否かをその式を表現する式構造体のフィールド“ｋｉｎ ｄ”２２０２（第２２図）と、代入演算子を指定するデータとを比較することに よって判定する。Ｃ言語においては、代入演算子（即ち“＝”）が、２つのオペ ランド、即ちｌｈｓ及びｒｈｓに対して演算を施し、ｒｈｓの値をｌｈｓに移す 。代入は、移された値を有する項目に評価される。例えば、式“ａ＝ｂ”は、項 目“ｂ”の値を項目“ａ”に移し、項目“ａ”の新たな値を有する項目に評価さ れる。 式の演算子が代入演算子でない場合には、処理は論理流れ図２９０２ （第３３Ａ図〜第３３Ｅ図）に従って、即ちステップ２９０２（第２９図）に従 って終了し、論理流れ図２９０２に従って処理された式はＮＵＬＬ値に評価され る。ＮＵＬＬ値は、有効値を持たない状態を示すために用いられる。 実行エンジン８０２（第８図）が、コンピュータプロセス内におけるサブジェ クト関数の実行の文脈を欠いた式を適切に評価することができない場合には、式 はＮＵＬＬ値に評価される。最も重要なことは、式の適切な評価ではなく、エク スターナル及びリソースのそれぞれの状態変化を追跡することである。この状態 の正確な追跡を確実に行うために、式の評価はできる限り多く行われる。 逆にテストステップ３３５３（第３３Ｅ図）において、式の演算子が代入演算 子である場合には、処理はステップ３３５３に進む。ステップ３３５３において は、実行エンジン８０２（第８図）は、論理流れ図２９００（第２９図）に従っ て式のｌｈｓを式そのものとして評価し、また演算は施さない。ステップ３３５ ４（第３３Ｅ図）から、処理はステップ３３５５に進み、ここでは実行エンジン ８０２（第８図）が論理流れ図２９００（第２９図）に従って式のｒｈｓの評価 を行い、また演算は施さない。処理はステップ３３５５（第３３Ｅ図）からステ ップ３３５６に進み、ここでは実行エンジン８０２（第８図）が、式のｒｈｓの 評価によって生成された項目の値を、式のｌｈｓの評価によって生成された項目 に代入する。ステップ３３５６については、後に論理流れ図３３５６（第４５図 ）に関連して詳細に説明する。ステップ３３５６（第３３Ｅ図）の終了後、処理 は論理流れ図２９０２に従って、即ちステップ２９０２（第２９図）に従って終 了する。 従って、ステップ２８０４（第２８図）においては、実行エンジン８０２（第 ８図）が、論理流れ図２９００（第２９図）に従って式の評価 ステップ３９０２においては、実行エンジン８０２（第８図）が、“ｒｅｔｕ ｒｎ”ステートメントが戻り値項目を指定しているか否かを判定する。“ｒｅｔ ｕｒｎ”ステートメントは、それが式を含んでいる場合、戻り値項目を指定する 。例えば、ステートメント構造体１４１６（第２１図）が“ｒｅｔｕｒｎ”ステ ートメントを表現している場合、フィールド“ｐｏｉｎｔｅｒｓ”２１１０は、 式構造体を指定する１つのポインタであるか、若しくはＮＵＬＬである。“ｒｅ ｔｕｒｎ”ステートメントが戻り値項目を指定する場合、即ちフィールド“ｐｏ ｉｎｔｅｒｓ”２１１０が式構造体を指定している場合、処理はテストステップ ３９０２（第３９図）からステップ３９０４に進み、ここで“ｒｅｔｕｒｎ”ス テートメントの式が論理流れ図２９００（第２９図）に従って評価され、また、 演算は施されない。ステップ３９０４（第３９図）において“ｒｅｔｕｒｎ”ス テートメントの式の評価において演算は施されないが、前にステップ３３０６、 ３３０７、及び３３１４（第３３Ａ−Ｂ図）に関連して説明したように、式のオ ペランドに何らかの演算を施すことも可能である。ステップ３９０４（第３９図 ）から処理はステップ３９０６に進み、ここでは実行エンジン８０２（第８図） がステップ３９０４（第３９図）において式の評価を行うことにより生成された 項目を、サブジェクト関数の戻り値項目を表現する項目構造体に代入する。１つ の項目の値を他の項目に代入することに関しては、後に詳しく説明する。 処理はステップ３９０６からステップ３９０８に進む。また、“ｒｅｔｕｒｎ ”ステートメントが戻り値項目を指定していない場合、処理はテストステップ３ ９０２から、直接ステップ３９０８に進む。ステップ３９０８においては、実行 エンジン８０２（第８図）が、後に詳述するように、サブジェクト関数の実行の エミュレーション時においてサブジェクト関数を通る制御の流れを与えるのに用 いられる“ｒｅｔｕｒｎ” 項目と等しく形成される。詳述すると、項目構造体２７００フィールド“ｒｅｓ ｏｕｒｃｅ”２７０２（第２７図）、“ｅｘｔｅｒｎａｌ”２７０４、“ｖａｌ ｕｅ”２７０６、“ｔｙｐｅ ｃｏｄｅ”２７１２、“ｉｎｉｔｉａｌｉｚｅｄ ”２７１４、及び“ｉｎｖａｌｉｄ ｐｏｉｎｔｅｒ”２７２０のそれぞれに対 応するｒｈｓ項目のフィールドに、データが格納される。処理はステップ４５０ ４（第４５図）からテストステップ４５０に進み、そこでは実行エンジン８０２ （第８図）がｒｈｓが初期化されたか否かを判定する。実行エンジン８０２は、 項目構造体２７００のフィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４（第２７ 図）に対応するｒｈｓ項目のフィールドと、ブール値“ｆａｌｓｅ”とを比較す ることによってこのような判定を行う。 ｒｈｓが初期化されている場合、即ち項目構造体２７００のフィールド”ｉｎ ｉｔｉａｌｉｚｅｄ”２７１４（第２７図）に対応するｒｈｓ項目のフィールド が、ブール値“ｔｒｕｅ”を有している場合には、処理は論理流れ図３３５６に 従って、即ちステップ３３５６（第３３Ｅ図）に従って終了する。逆に、ｒｈｓ が初期化されていない場合、即ち項目構造体２７００のフィールド“ｉｎｉｔｉ ａｌｉｚｅｄ”２７１４（第２７図）に対応するｒｈｓ項目のフィールドがブー ル値“ｆａｌｓｅ”を有している場合には、処理はテストステップ４５０６（第 ４５図）からステップ４５０８に進む。ステップ４５０８においては、上述のよ うにエラーメッセージがエラーログファイル及び／若しくはビデオモニタ１１８ 上のディスプレイに対して送られて、初期化されていないデータが使用されてい ることを警告する。フィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４（第２７図 ）に対応するｒｈｓ項目のフィールドが、上述のようにステップ４５０４におい て、ｌｈｓ項目における対応するフィールドにコピーされることから、ｌｈｓ項 目も初期化されていない旨の 印付けがなされる。ステップ４５０８（第４５図）が終了した後、論理流れ図３ ３５６に従って、即ちステップ３３５６（第３３Ｃ図）に従って処理を終了する 。 上述のように、ｌｈｓ若しくはｒｈｓの何れかが項目によって表現されない場 合、処理はテストステップ４５０２（第４５図）からテストステップ４５１０に 進む。テストステップ４５１０において、実行エンジン８０２（第８図）が、ｒ ｈｓ及びｌｈｓが個別に項目によって表現されるか否かを判定する。ｌｈｓが項 目によって表現され、ｒｈｓが項目によって表現されない場合には、処理はテス トステップ４５１０（第４５図）からステップ４５１２に進む。そうでない場合 には、処理は論理流れ図３３５６に従って、即ちステップ３３５６（第３３Ｅ図 ）に従って終了する。 ステップ４５１２（第４５図）においては、実行エンジン８０２（第８図）が ｌｈｓ項目に未知なものとしての印付けを行う。例えば、項目構造体２７００（ 第２７図）がｌｈｓ項目を表現する場合、実行エンジン８０２（第８図）が、（ ｉ）未知のデータの型を示すデータをフィールド“ｔｙｐｅ ｃｏｄｅ”２７１ ２（第２７図）に格納し、（ｉｉ）ｌｈｓ項目が初期化されていないことを示す データをフィールド“ｉｎｉｔｉａｌｉｚｅｄ”２７１４に格納し、（ｉｉｉ） ｌｈｓがエクスターナル若しくはリソースと関連付けられていないことを示すべ くフィールド“ｒｅｓｏｕｒｃｅ”２７０２及び“ｅｘｔｅｒｎａｌ”２７０４ にＮＵＬＬを格納することによって、ｌｈｓが既知でないという印付けを行う。 ステップ４５１２（第４５図）の終了後、処理は論理流れ図３３５６に従って、 即ちステップ３３５６（第３３Ｅ図）に従って終了する。 従って、ステップ３３５６において、ｒｈｓを表現する項目の値はｌ ｈｓを表現する項目に代入される。上述のように、実行エンジン８０２（第８図 ）が、ステップ３４０８（第３４図）において式の評価によって得られた項目の 値を、宣言された項目に代入する。ステップ３４０８におけるこの代入は、論理 流れ図３３５６（第４５図）に関連して上述したｒｈｓ項目のｌｈｓ項目への代 入に類似したものである。ステップ３８１２（第３８図）に関して上述したよう に、実行エンジン８０２（第８図）は、既知の項目の値を未知の項目に代入する 。ステップ３８１２（第３８図）における既知の項目の未知の項目への代入は、 論理流れ図３３５６に関連して上述したｒｈｓ項目のｌｈｓ項目への代入に類似 したものである。上述のように、実行エンジン８０２（第８図）は、ステップ３ ９０６（第３９図）において、式の評価によって得られた項目の値を戻り値項目 に代入する。ステップ３９０６におけるこの代入処理は、論理流れ図３３５６（ 第４５図）に関連して上述したｒｈｓ項目のｌｈｓ項目への代入に類似したもの である。関数のエミュレーション 上述のように、実行エンジン８０２（第８図）は、ステップ３３５２（第３３ Ｅ図）において、関数の実行をエミュレートすることにより関数の呼出しを評価 する。ステップ３３５２は論理流れ図３３５２（第４６図）に詳細に示されてお り、ここでは処理がステップ４６０２から始まる。関数の呼出しの実行は、呼び 出される関数の挙動を表現する関数モデル構造体に従ってエミュレートされる。 テストステップ４６０２において、実行エンジン８０２（第８図）は、呼び出さ れる関数の挙動を表現する関数モデル構造体が、メモリ１０４（第１図）に格納 されているか否かを判定する。上述のように、関数モデル構造体１１００（第１ １図）は、関数モデル構造体１１００によってその挙動が表現される関数の識別 子を表現するデータを含んでいるフィールド“ｎａｍｅ”１１ ０２を有する。各関数の挙動を表現する様々な関数モデル構造体の対応するフィ ールドは、サブジェクト関数がその関数を呼び出すのに用いる識別子と比較され るが、これは全ての関数モデル構造体がチェックされるまでか、若しくはそのフ ィールド“ｎａｍｅ”が識別子と一致する関数モデル構造体が見つけられるまで 続けて行われる。 その識別子と一致するフィールド“ｎａｍｅ”を有する関数モデル構造体が見 つけられない場合は、処理はテストステップ４６０２（第４６図）からステップ ４６０４に進み、ここで呼び出される関数の実行のエミュレーションを評価する ことによって得られる項目としてＮＵＬＬが生成される。上述のように、実行エ ンジン８０２（第８図）がその式を適切に評価するための十分な情報を有してい ないときには、式はＮＵＬＬに評価される。ステップ４６０４（第４６図）の実 行の後、処理は論理流れ図３３５２に従って、即ちステップ３３５２（第３３Ｅ 図）に従って終了する。 一方、そのフィールド“ｎａｍｅ”が、サブジェクト関数が関数の呼出しに用 いる識別子と一致するような関数モデル構造体、即ち呼び出される関数の挙動を 表現する関数モデル構造体が見つけれられた場合には、処理はテストステップ４ ６０２（第４６図）からループステップ４６０６に進む。ループステップ４６０ ６及びＮＥＸＴステップ４６３０はループを形成し、このループの中で呼び出さ れる関数の関数モデル構造体内のエクスターナルモデル構造体によって表現され る各エクスターナルが処理される。第１３図に関連して以前に説明したように、 関数モデル構造体１１００Ａのような関数モデル構造体は、エクスターナルモデ ル構造体のシングルリンクトリストにおける第１エクスターナルモデル構造体を 指定するフィールド“ｆｉｒｓｔ ｅｘｔｅｒｎａｌ”１１０４Ａを含む。呼び 出される関数の関数モデル構造体のエクスターナルモデ ル構造体のシングルリンクトリストの各エクスターナルに対して、処理はループ ステップ４６０６（第４６図）からテストステップ４６０８に進む。呼び出され る関数の関数モデル構造体のエクスターナルモデル構造体のシングルリンクトリ ストの各エクスターナルが処理された後、処理はループステップ４６０６から以 下に詳細に説明するステップ４６３２に進む。 以下のステップ４６０８〜４６２８の説明の文脈においては、ループステップ ４６０６及びＮＥＸＴステップ４６３０により形成されるループに従って処理さ れるエクスターナルモデル構造体には、エクスターナルモデル構造体の処理の説 明のための例として、エクスターナルモデル構造体１２００（第１２図）を用い るものとする。テストステップ４６０８（第４６図）において、実行エンジン８ ０２（第８図）が、エクスターナルモデル構造体１２００（第１２図）がパラメ ータを表現しているか否かを、フィールド“ｔｙｐｅ”１２０４とパラメータを 示すデータとを比較することによって判定する。エクスターナルモデル構造体１ ２００がパラメータを表現していない場合には、処理はテストステップ４６０８ （第４６図）から以下に詳細に説明するテストステップ４６１２に進む。逆に、 エクスターナルモデル構造体１２００（第１２図）がパラメータを表現している 場合には、処理はテストステップ４６０８（第４６図）からステップ４６１０に 進む。 ステップ４６１０においては、実行エンジン８０２（第８図）がそのパラメー タを表現する項目を検索する。ループステップ３３４８（第３３Ｅ図）、ステッ プ３３４９、及びＮＥＸＴステップ３３５０に関連して以前に説明したように、 実行エンジン８０２（第８図）は、呼び出される関数のパラメータを表現する項 目の配列を含む。エクスターナルモデル構造体１２００（第１２図）によって表 現される特定のパラメータ る場合には、そのエクスターナルは、呼び出される関数の戻り値項目である。エ クスターナルが呼び出される関数の戻り値項目でない場合には、そのエクスター ナルを表現する宣言構造体１５０６のフィールド“ｉｔｅｍ”１６０８（第１６ 図）に新たな項目が形成される。 ステップ４６２８（第４６図）から、処理はＮＥＸＴステップ４６３０を通っ てループステップ４６０６に進み、ここで上述のように次のエクスターナルが処 理される。呼び出される関数を表現する関数モデル構造体１１００のフィールド “ｆｉｒｓｔ ｅｘｔｅｒｎａｌ”１１０４（第１１図）及び“ｌａｓt ｅｘ ｔｅｒｎａｌ”１１０６によって指定されるエクスターナル構造体のシングルリ ンクトリストにおけるエクスターナル構造体によって表現されるエクスターナル の全てがひとたび処理されると、処理はループステップ４６０６（第４６図）か らステップ４６３２に進む。ステップ４６３２において、実行エンジン８０２（ 第８図）は、呼び出される関数の実行のエミュレーションにより評価して得られ た項目として、結果レコードを生成する。ステップ４６２８（第４６図）に関連 して上述したように、この結果レコードはＮＵＬＬ値に初期化され、戻り値項目 の代わりに新たなリソースが生成された場合には、戻り値項目の値に設定される 。 ステップ４６３２の終了後、処理は論理流れ図３３５２に従って、即ちステッ プ３３５２（第３３Ｅ図）に従って終了する。従って、呼び出される関数の挙動 を表現するモデルを用いることによって、サブジェクト関数内に呼び出される関 数に対する呼出しを評価して、呼び出される関数の実行のリソース及びエクスタ ーナルに対する評価を解析することができる。メモリの集群 Ｃ言語に特有なことの１つは、あるメモリを、連続して割り当てられ 【図１】 【図２】 【図３】 【図３】 【図４】 【図４】 【図５】 【図５】 【図６】 【図７】 【図８】 【図９】 【図１０】 【図１１】 【図１２】 【図１３】 【図１４】 【図１５】 【図１６】 【図１７】 【図１８】 【図１９】 【図２０】 【図２１】 【図２２】 【図２３】 【図２４】 【図２５】 【図２６】 【図２７】 【図２８】 【図２９】 【図３０】 【図３１】 【図３２】 【図３３】 【図３３】 【図３３】 【図３３】 【図３３】 【図３４】 【図３９】 【図３５】 【図３６】 【図３７】 【図４３】 【図３８】 【図４０】 【図４１】 【図４２】 【図４５】 【図４４】 【図４６】 【手続補正書】特許法第１８４条の８第１項 【提出日】１９９６年８月２７日 【補正内容】 成されるコンピュータプロセスを、全ての可能な制御流れ経路を通るようにする ことは実際的ではない。そのようにするには、プログラマーが、コンピュータプ ログラムのコンピュータ命令の実行時に発生し得る全ての事象を予期し、そのよ うな事象発生の全ての組み合わせを生じさせるまたはエミュレートすることが必 要であるからである。 更に、ランタイムチェックは、コンピュータプログラムが完成しているときし か使用することができない。ランタイムチェックでは、ある１つの関数が完成し たプログラムに組み込まれる前に、その関数を解析することは不可能である。な ぜなら、解析するにはその関数を実行しなければならないからである。従って、 ランタイムチェックを用いて関数を解析するには、（ｉ）コンピュータプログラ ムの全ての関数が、それらの関数のどれかを解析するよりも前に、開発され、組 み合わされてコンピュータプログラムを形成していること、または（ｉｉ）その 関数を組み込んだ特別なテストプログラムが開発されていることが必要である。 従って、完成したコンピュータプログラムへの組み込み前に個々の関数の設計、 制作及びテストを行う、複雑なコンピュータプログラムを開発する好適な方法で あり広く知られているトップダウン式のプログラミングは、ランタイム解析には なじまない。 スズキらに付与された米国特許第５，２５３，１５８号（以下「スズキ」と言 う）明細書には、自動化さた機器の動作を制御するために用いられるべきソウト ウェア（シーケンサソウトウェア）の実行時間チェックを行う装置が開示されて いる。「スズキ」によれば、自動化された機器を用いずにシーケンサソフトウェ アの試験ができる。「スズキ」の発明では、ソフトウェアの動作環境に関する情 報、自動化された機器の特性に関する情報、実行されるべきテストケースに関す る情報が、記憶装置に格納されている（第１図）。次に、「スズキ」の発明では 、シーケ ンサソフトウェアによって制御された自動化された機器の動作をシミュレートし 、シミュレートされた結果が得られる（第１欄の第５４行から第５９行）。「ス ズキ」の発明のシミュレーションは、シーケンサソフトウェアの実行を必要とす る（第４欄の第５０行）。「スズキ」に開示された実行時間チェック装置は、こ れまで説明されたように、実行時間の解析の限界に対する主題であった。 フ・ティン・チャン及びツォン・ユゥエ・チェンは、「ＡＩＤＡ−Ａ Ｄｙｎａｍ ｉｃ Ｄａｔａ Ｆｌｏｗ Ａｎｏｍａｌｙ Ｄｅｔｅｃｔｉｏｎ Ｓｙｅｔｅ ｍ ｆｏｒ Ｐａｓｃａｌ Ｐｒｏｇｒａｍｓ， Ｓｏｆｔｗａｒｅ Ｐｒａｃ ｔｉｃｅ Ａｎｄ Ｅｘｐｅｒｉｅｎｃｅ第２２７頁−第２３９頁（１９８７年 ３月）」で、パスカルプログラム用の動的データ流れ解析システムについて説明 している。ＡＩＤＡ（ａｕｔｏｍａｔｅｄ ｉｎｓｔｒｕｃｔｉｏｎ ｓｙｓｔ ｅｍ）は、文法的に補正されたパスカルプログラムを解析し、このプログラムを インストラクションプログラムに変換する。インストラクションプログラムは、 もとのパスカルソースコードに挿入された変数の状態を初期化、追従、若しくは チャックするための手続コールの形式を検査する。プログラムの実行中、ＡＩＤ Ａは、データの流れの異常と、初期化されていない変数、変数の不正な使用、変 数の誤った分類化、定義された変数の意図しない破壊などのプログラミングエラ ーを検出する。ＡＩＤＡは、上述されたように、実行時間解析の限定に対する主 題となっている。 必要とされているのは、コンピュータプログラムの動的な挙動を考慮し、自動 的にコンピュータプログラムの概ね全ての制御流れ経路を考慮し、コンピュータ プログラムのプログラマーがコンピュータプログラムを別の形式、例えば数学的 形式、で表すことを必要としないプログラミングエラー検出技術である。更に必 要とされているのは、プログラムの 個々のコンポーネントを、実行時のそのコンポーネントの挙動を考慮して解析す るプログラミングエラー検出技術である。更に必要とされているのは、解析中の コンピュータプログラムコンポーネントによって実行請求の範囲 １．１つ若しくは複数のステートメントを有する電子計算機用プログラムのコン ポーネントの挙動の解析方法であって、 （ａ）有効な状態を定義する過程と、 （ｂ）前記１つ若しくは複数のステートメントを通る制御流れ経路を通過する 過程と、 （ｃ）前記コンポーネントを動的に検査する過程と、 （ｄ）前記コンポーネントの効果を記述する過程とを有することを特徴とする 電子計算機用プログラムのコンポーネントの挙動の解析方法。 ２．（ａ）前記定義する過程が、リソース状態を有するリソースに対して１つ若 しくは複数の有効な状態を定義し、 （ｂ）前記動的に検査する過程が、前記制御流れ経路に沿った前記１つ若しく は複数のステートメントの各々に対して、（１）前記リソースの前記リソース状 態に対する前記ステートメントの効果を評価する過程と、（２）前記効果に基づ いて前記リソースの新たなリソース状態の前記リソース状態からの遷移をモデル 化する過程とを実行し、 （ｃ）前記記述する過程の前記新たな状態が前記有効な状態の何れでもないこ とを検出する過程を有することを特徴とする請求項１に記載の方法。 ３．前記コンポーネントが関数からなることを特徴とする請求項１若しくは２に 記載の方法。 ４．前記通過する過程が、 前記１つ若しくは複数のステートメントの選択されたステートメントが、述語 の値に基づいて前記制御流れ経路の一部を決定するか否かを判定する過程と、 前記制御流れ経路を決定するために前記述語を評価する過程とを有す ることを特徴とする請求項１若しくは２に記載の方法。 ５．前記述語を評価する前記過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を割り当てる過程とを有することを特徴とする請求項４ に記載の方法。 ６．前記述語を評価する過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する過程を更 に有することを特徴とする請求項５に記載の方法。 ７．前記述語を評価する過程が、 前記想定した値から前記述語の１つまたは複数のオペランドの各々の値を推論 する過程を更に有することを特徴とする請求項５に記載の方法。 ８．前記通過する過程が、 前記１つ若しくは複数のステートメントの第２の選択されたステートメントが 、前記第１の述語の前記１つ若しくは複数のオペランドを有する第２の述語の第 ２の値に基づいて前記制御流れ経路の第２の部分を決定するか否かを判定する過 程と、 前記第１の述語の前記１つ若しくは複数のオペランドの前記推論された各々の 値を用いて、前記制御流れ経路の前記第２の部分を決定するために前記第２の述 語を評価する過程とを更に有することを特徴とする請求項７に記載の方法。 ９．前記過程（ｂ）の前記過程（１）が、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しであるか 否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しである場 合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネント の前記効果を評価するために、前記呼び出されたコン ポーネントの実行をエミュレートする過程とを有することを特徴とする請求項１ 若しくは２に記載の方法。 １０．（ａ）前記定義する過程が、リソース状態を有するリソースに対する１つ 若しくは複数の有効な状態を定義する過程を有し、 （ｂ）各々が前記有効な状態の第１の状態から前記有効な状態の第２の状態へ の遷移からなる１つ若しくは複数の有効な状態の遷移を定義する過程を有し、 （ｃ）前記動的に検査する過程が、前記制御流れ経路に沿って前記１つ若しく は複数のステートメントの各々に対し、（１）前記リソースの前記リソース状態 に対する前記ステートメントの効果を評価する過程と、（２）前記効果に基づき 前記リソースの前記リソース状態の変化をモデル化する過程とを実行し、 （ｄ）前記記述する過程が、前記変化が前記有効な状態の遷移の何れでもない ことを検出する過程を有することを特徴とする請求項１に記載の方法。 １１．前記述語を評価する過程が、 前記想定した値から前記述語の前記１つ若しくは複数の要素の各々の値を推論 する過程を更に有することを特徴とする請求項５に記載の方法。 １２．前記通過する過程が、 前記１つ若しくは複数のステートメントの第２の選択されたステートメントが 、前記第１の述語の前記１つ若しくは複数の要素を有する第２の述語の第２の値 に基づいて前記制御流れ経路の第２の部分を決定するか否かを判定する過程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語を 評価する過程とを更に有することを特徴とする請求項 １１に記載の方法。 １３．前記過程（ｃ）の前記過程（１）が、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しからなる か否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しからなる 場合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネン トの前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミ ュレートする過程とを有することを特徴とする請求項１０に記載の方法。 １４．前記呼び出されたコンポーネントの実行をエミュレートする前記過程が、 前記リソースが前記呼び出されたコンポーネントのエクスターナルに関連して いるか否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルに関連す る前記ソースに対する前記コンポーネントの実行の前記効果を決定する過程とを 有することを特徴とする請求項９若しくは１３に記載の方法。 １５．前記リソース状態が前記有効な状態の何れでもないことをユーザに通知す る過程を更に有することを特徴とする請求項１、２及び１０に何れかに記載の方 法。 １６．その前記リソース状態に対する効果が前記有効な状態の何れでもない新た なリソース状態への遷移を引き起こすという効果である前記ステートメントを、 ユーザに対して特定する過程を更に有することを特徴とする請求項１、２及び１ ０の何れかに記載の方法。 １７．前記コンポーネントがエクスターナルを含み、 （ａ）前記定義する過程が、エクスターナル状態を有する前記エクス ターナルに対する１つ若しくは複数の有効な状態を定義する過程を有し、 （ｂ）前記動的に検査する前記過程が、前記１つ若しくは複数のステートメン トの各々に対し、（１）前記ステートメントの実行が、前記エクスターナルの前 記エクスターナル状態に対して効果を有するか否かを判定する過程と、（２）前 記効果に基づいて前記エクスターナル状態から前記エクスターナルの新たなエク スターナル状態への遷移をモデル化する過程とを有し、 （ｃ）前記記述する過程が、前記エクスターナルの前記コンポーネントの前記 ステートメントの共通の効果を表すモデルを構築する過程を有することを特徴と する請求項１に記載の方法。 １８．前記通過する過程が、 前記１つ若しくは複数のステートメントの選択されたステートメントが、述語 の値に基づいて前記制御流れ経路の一部を決定するか否かを判定する過程と、 前記制御流れ経路を決定するために、前記述語を評価する過程とを有すること を特徴とする請求項１７に記載の方法。 １９．前記述語を評価する過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を割り当てる過程とを有することを特徴とする請求項１ ８に記載の方法。 ２０．前記述語を評価する過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する仮定を更 に有することを特徴とする請求項１９に記載の方法。 ２１．前記述語を評価する過程が、 前記想定した値から前記述語の１つ若しくは複数のコンポーネントの各々の値 を推論する過程を更に有することを特徴とする請求項１９に記 載の方法。 ２２．前記通過する過程が、 前記１つ若しくは複数のステートメントの第２の選択されたステートメントが 、前記第１の述語の前記要素の１つ若しくは複数を有する第２の述語の第２の値 に基づいて前記制御フローバスの第２の部分を決定するか否かを判定する過程と 、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語を 評価する過程とを更に有することを特徴とする請求項２１に記載の方法。 ２３．前記述語を評価する過程が、 前記想定した値から前記エクスターナルの前記状態に関する情報を推論する過 程を更に有することを特徴とする請求項１９に記載の方法。 ２４．前記過程（ｂ）の前記過程（１）が、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しであるか 否かを判定する過程と、 前記ステートメントが前記呼び出されたコンポーネントに対する呼び出しであ る場合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネ ントの前記効果を評価するために、前記呼び出されたコンポーネントの実行をエ ミュレートする過程とを有することを特徴とする請求項１７に記載の方法。 ２５．前記呼び出されたコンポーネントの実行をエミュレートする前記過程が、 前記リソースが前記呼び出されたコンポーネントのエクスターナルに関連する か否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナル に関連する前記リソースに対する前記コンポーネントの実行の前記効果を求める 過程とを有することを特徴とする請求項２４に記載の方法。 ２６．（ｄ）１つ若しくは複数のステートメントからなる第２の集合を有する第 ２の制御流れ経路を通過する過程と、 （ｅ）前記１つ若しくは複数のステートメントの第２の集合の各々のステート メントに対し、（１）前記ステートメントの実行が前記エクスターナルの前記エ クスターナル状態に対する効果を有するか否かを判定する過程と、（２）前記効 果に基づいて前記エクスターナル状態から第２の新たなエクスターナル状態への 遷移をモデル化する過程とを実行する過程と、 （ｆ）前記第１の新たなエクスターナル状態と前記第２の新たなエクスターナ ル状態とから前記エクスターナルの共通のエクスターナル状態を形成する過程と を更に有することを特徴とする請求項１７に記載の方法。 ２７．前記通過する過程が、 前記１つ若しくは複数のステートメントの選択されたステートメントが、述語 の値に基づいて前記第２の制御流れ経路の一部を決定するか否かを判定する過程 と、 前記第２の制御流れ経路を決定するために、前記述語を評価する過程とを有す ることを特徴とする請求項２６に記載の方法。 ２８．前記述語を評価する過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を割り当てる過程とを有することを特徴とする請求項２ ７に記載の方法。 ２９．前記述語を評価する過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する 過程を更に有することを特徴とする請求項２８に記載の方法。 ３０．前記述語を評価する過程が、 前記想定した値から前記述語の１つ若しくは複数の要素の各々の値を推論する 過程を更に有することを特徴とする請求項２８に記載の方法。 ３１．前記述語を評価する過程が、 前記想定した値から前記エクスターナルの前記状態に関する情報を推論する過 程を更に有することを特徴とする請求項２８に記載の方法。 ３２．前記通過する過程が、 前記１つ若しくは複数のステートメントの第２の選択されたステートメントが 、前記第１の述語の前記１つ若しくは複数の要素を有する第２の述語の第２の値 に基づいて、前記制御流れ経路の第２の部分を決定するか否かを判定する過程と 、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語を 評価する過程を更に有することを特徴とする請求項３２記載の方法。 ３３．前記過程（ｅ）の前記過程（１）は、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しであるか 否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しである場 合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネント の前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミュ レートする過程とを有することを特徴とする請求項２６に記載の方法。 ３４．前記呼び出されたコンポーネントの実行をエミュレートする前記過程が、 前記リソースが前記呼び出されたコンポーネントのエクスターナルに関連する か否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルに関連す る前記ソースに対する前記コンポーネントの実行の前記効果を求める過程とを有 することを特徴とする請求項３３に記載の方法。 ３５．前記エクスターナルの前記共通の状態から前記コンポーネントの前記挙動 のモデルを導き出す過程を更に有することを特徴とする請求項２６に記載の方法 。 ３６．前記コンポーネントの前記挙動の前記モデル内に、前記エクスターナルの 前記状態での１つ若しくは複数の遷移を指示する情報を包含させる過程を更に有 することを特徴とする請求項３５に記載の方法。 ３７．前記第１のコンポーネントに対する呼び出しを含む前記電子計算機用プロ グラムの呼び出しコンポーネントの解析の間、前記モデルを用いて、前記エクス ターナルに対する前記第１のコンポーネントの実行の前記効果を求める過程を更 に有することを特徴とする請求項１７に記載の方法。 ３８．前記コンポーネントがリソースの利用を指示し、 （ａ）前記定義する過程が、リソース状態を有する前記リソースに対する１つ若 しくは複数の有効な状態を定義する過程を有し、 （ｂ）前記動的に検査する過程が、前記１つ若しくは複数のステートメントの各 々に対して、（１）前記ステートメントの実行が前記リソースの前記エクスター ナルの状態に対し効果を有するか否かを判定する過程と、（２）前記効果に基づ いて前記リソースの状態から新たなリソースの状態への遷移をモデル化する過程 とを実行する過程を有し、 （ｃ）前記記述する過程が、前記リソースの前記コンポーネントの前記ステート メントの共通の効果を表すモデルを構築する過程を有すること を特徴とする請求項１に記載の方法。 ３９．前記通過する過程が、 前記１つ若しくは複数のステートメントの選択されたステートメントが、述語 の値に基づいて前記制御流れ経路の一部を決定するか否かを判定する過程と、 前記制御流れ経路を決定するために前記述語を評価する過程とを有することを 特徴とする請求項３８に記載の方法。 ４０．前記述語を評価する過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を割り当てる過程とを有することを特徴とする請求項３ ９に記載の方法。 ４１．前記述語を評価する過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する過程を更 に有することを特徴とする請求項４０に記載の方法。 ４２．前記述語を評価する過程が、 前記想定した値から前記述語の１つ若しくは複数の要素の各々の値を推論する 過程を更に有することを特徴とする請求項４０に記載の方法。 ４３．前記通過する過程が、 前記１つ若しくは複数のステートメントの第２の選択されたステートメントが 、 前記第１の述語の１つ若しくは複数の前記要素を有する第２の述語の第２の値 に基づいて前記制御流れ経路の第２の部分を決定するか否かを判定する過程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために前記第２の述語を評 価する過程を更に有することを特徴とする請求項４２ に記載の方法。 ４４．前記過程（ｂ）の前記過程（１）が、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しであるか 否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しである場 合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネント の前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミュ レートする過程とを有することを特徴とする請求項３８に記載の方法。 ４５．前記呼び出されたコンポーネントの実行をエミュレートする前記過程が、 前記リソースが前記呼び出されたコンポーネントのエクスターナルと関連する か否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルと関連す る前記リソースに対する前記コンポーネントの実行の前記効果を求める過程とを 有することを特徴とする請求項４４に記載の方法。 ４６．（ｄ）１つ若しくは複数のステートメントからなる第２の集合を有する第 ２の制御流れ経路を通過する過程と、 １つ若しくは複数のステートメントの前記第２の集合の各ステートメントに対 して、（１）前記ソースの前記リソース状態に対する前記ステートメントの効果 を評価する過程と、（２）前記効果に基づいて前記リソースの状態から第２の新 たなリソースの状態への遷移をモデル化する過程とを実行する過程と、 （ｆ）前記第１の新たなリソースの状態と前記第２の新たなリソースの状態とか ら前記リソースの共通のリソース状態を形成する過程とを更に有することを特徴 とする請求項３８に記載の方法。 ４７．前記通過する過程が、 前記１つ若しくは複数のステートメントの選択されたステートメントが、述語 の値に基づいて前記制御流れ経路の一部を決定するか否かを判定する過程と、 前記制御流れ経路を求めるために、前記述語を評価する過程とを有することを 特徴とする請求項４６に記載の方法。 ４８．前記述語を評価する前記過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に仮定され値を割り当てる過程とを有することを特徴とする請求項４ ７に記載の方法。 ４９．前記述語を評価する過程が、前記想定した値から前記リソースの前記状態 に関する情報を推論する過程を更に有することを特徴とする請求項４８に記載の 方法。 ５０．前記述語を評価する過程が、 前記想定した値から前記述語の１つ若しくは複数の要素の各々の値を推論する 過程を更に有することを特徴とする請求項４８に記載の方法。 ５１．前記通過する過程が、前記１つ若しくは複数のステートメントの第２の選 択されたステートメントが、前記第１の述語の１つ若しくは複数の前記要素を有 する第２の述語の第２の値に基づいて前記制御流れ経路の第２部分を決定するか 否かを判定する過程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語を 評価する過程とを更に有することを特徴とする請求項５０に記載の方法。 ５２．前記過程（ｆ）の前記過程（１）が、 前記ステートメントが呼び出されたコンポーネントに対する呼び出し であるか否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しからなる 場合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネン トの前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミ ュレートする過程とを更に有することを特徴とする請求項４６に記載の方法。 ５３．前記呼び出されたコンポーネントの実行をエミュレートする前記過程が、 前記リソースが前記呼び出されたコンポーネントのエクスターナルと関連する か否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルと関連す る前記リソースに対する前記コンポーネントの実行の前記効果を求める過程とを 有することを特徴とする請求項５２に記載の方法。 ５４．前記リソースの前記共通の状態から、前記コンポーネントの前記挙動のモ デルを導き出す過程を更に有することを特徴とする請求項４６に記載の方法。 ５５．前記コンポーネントの前記挙動の前記モデル内に、前記リソースの前記状 態での１つ若しくは複数の遷移を表示する情報を包含させる過程を更に有するこ とを特徴とする請求項５４に記載の方法。 ５６．前記第１のコンポーネントに対する呼び出しを含む前記電子計算機用プロ グラムの呼び出しコンポーネントを解析する間に、前記モデルを用いて、前記リ ソースに対する前記第１のコンポーネントの実行の前記効果を求める過程を更に 有することを特徴とする前記３８に記載の方法。 ５７．電子計算機用プログラムの呼び出しコンポーネントの前記呼び出しコンポ ーネントの項目に対する実行の効果の解析方法であって、 前記呼び出しコンポーネントがその項目がエクスターナルからなる呼び出され たコンポーネントに対する呼び出しを含むか否かを判定する過程と、 前記呼び出されたコンポーネントの１つ若しくは複数のエクスターナルに対す る前記呼び出されたコンポーネントの実行の効果を記述するコンポーネントモデ ルから、前記項目に対する前記呼び出されたコンポーネントの実行の前記効果を 求める過程とを有することを特徴とする項目に対する実行の効果の解析方法。 ５８．前記項目が状態を有し、 前記項目に対する前記呼び出されたコンポーネントの実行の前記効果を求める 前記過程が、前記呼び出されたコンポーネントによって指示さた前記項目の前記 状態の変化を求める過程を有することを特徴とする請求項５７に記載の方法。 ５９．前記呼び出されたコンポーネントが、前記項目の前記状態に施されるべき １つ若しくは複数のオペレーションを指定することよって、前記項目の前記状態 の変化を指示することを特徴とする請求項５８に記載の方法。 ６０．前記呼び出されたコンポーネントが、前記項目の前記状態の有効な状態か ら無効な状態への遷移を指示するか否かを判定する過程を更に有することを特徴 とする請求項５８に記載の方法。 ６１．前記呼び出されたコンポーネントが、第１の有効な状態から第２の有効な 状態への遷移以外の前記項目の状態の遷移を指示するものであるか否かを判定す る過程を更に有することを特徴とする請求項５８に記載の方法。 ６２．電子計算機用プログラムのコンポーネントのプログラミングエラーの検出 方法であって、 その利用が前記コンポーネントの１つ若しくは複数のステートメントによって 指示されたリソースが、１つ若しくは複数の状態にあるか否かを判定する過程と 、 前記コンポーネントが、前記１つ若しくは複数の状態のある特定の状態にある ことを要する第１の状態に前記リソースがあること、及び前記第１のステートメ ントが、実行それることによって前記特定の状態に前記リソースがあることを確 かめ第２のステートメントによって、前記コンポーネントを通る制御流れ経路に おいて先行されていないことを検知する過程とを有することを特徴とするプログ ラミングエラーの検出方法。 ６３．前記１つ若しくは複数の状態が、確実に割り当てられた状態と確実に割り 当てられていない状態とを有することを特徴とする請求項６２に記載の方法。 ６４．前記特定の状態が前記確実に割り当てられた状態であることを特徴とする 請求項６３に記載の方法。 ６５．１つ若しくは複数のリソースの利用を指示するステートメントを含み、か つ１つ若しくは複数のエクスターナルを含む電子計算機用プログラムのコンポー ネントのリソースのリークの検出方法であって、 前記１つ若しくは複数のリソースの何れが前記１つ若しくは複数のエクスター ナルの任意のエクスターナルによって到達可能であるか否かを判定する過程と、 エクスターナルによって到達可能ではない任意のリソースが、割り当てられて いるか否かを判定する過程とを有することを特徴とする電子計算機用プログラム のコンポーネントのリソースのリークの検出方法。 ６６．前記１つ若しくは複数のリソースの何れのリソースが到達可能であるかを 判定する前記過程が、 前記コンポーネントのエクスターナルの、前記リソースに到達するた めの項目を含む集群内にあるか否かを判定する過程を有することを特徴とする請 求項６５に記載の方法。 ６７．電子計算機用プログラムのコンポーネントのデータフロー解析の実施方法 であって、 前記コンポーネントのステートメントが、述語の値に基づいて制御を遷移させ る１つ若しくは複数の要素を備えた条件付けられた分岐ステートメントとからな るか否かを判定する程と、 前記述語が第１の値を有すと仮定する過程と、 前記第１の値から、前記述語の前記１つ若しくは複数の要素の各々の値を推論 する過程とを有することを特徴とするデータフロー解析の実施方法。 ６８．前記述語の前記第１の値に基づいて、前記条件付けられた分岐ステートメ ントを有する前記コンポーネントを通る制御流れ経路を通過する過程を更に有す ることを特徴とする請求項６７に記載の方法。 ６９．前記コンポーネントの第２のステートメントが、第２の述語の第２の値に 基づいて制御を遷移させる前記第１の述語の前記１つ若しくは複数の要素を含む 第２の条件付けられた分岐ステートメントであるか否かを判定する過程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値から 、前記第２の値を求める過程とを更に有することを特徴とする請求項６７に記載 の方法。 ７０．１つ若しくは複数のステートメントを有する電子計算機用プログラムのコ ンポーネントのプログラミングエラーを検出するリソースチェッカであって、 リソース状態を有するリソースに対する１つ若しくは複数の有効な状態を定義 するリソース挙動モデルと、 前記１つ若しくは複数のステートメントを通る制御流れ経路を通過すると共に 前記のリソースの前記リソース状態に対するそれぞれの効果を前記１つ若しくは 複数のステートメントの各々が有するか否かを判定する実行エンジンと、 前記１つ若しくは複数のステートメントの各々の前記効果に基づいて、前記リ ソースの状態から新たなリソースの状態への遷移をモデル化すると共に前記新た なリソースの状態が前記有効な状態でないことを検知する状態マシンとを有する ことを特徴とするリソースチェッカ。 ７１．前記コンポーネントが関数からなることを特徴とする請求項７０に記載の リソースチェッカ。 ７２．前記実行エンジンが、前記１つ若しくは複数のステートメントの選択され たステートメントが述語の値に基づいて前記制御流れ経路の一部を決定するか否 かを判定すると共に前記制御流れ経路を決定するために前記述語を評価すること を特徴とする請求項７０に記載のリソースチェッカ。 ７３．前記実行エンジンが、前記述語の前記値が未知の値であるか否かを判定す ることによりかつ前記述語に想定した値を割り当てることにより、前記述語を評 価することを特徴とする請求項７２に記載のリソースチェッカ。 ７４．前記実行エンジンが、前記想定した値から前記リソースの前記状態に関す る情報を推論することを特徴とする請求項７３に記載のリソースチェッカ。 ７５．前記実行エンジンが、前記想定した値から前記述語の１つ若しくは複数の 要素の各々の値を推論することを特徴とする請求項７３に記載のリソースチェッ カ。 ７６．前記実行エンジンが、前記第１の述語の前記１つ若しくは複数の 要素を有する第２の述語の第２の値に基づいて、前記１つ若しくは複数のステー トメントの第２の選択されたステートメントが前記制御流れ経路の第２の部分を 決定するか否かを判定し、 前記実行エンジンが、前記第１の述語の前記１つ若しくは複数の要素の前記推 論された各々の値を用いて、前記制御流れ経路の前記第２の部分を決定するため に前記第２の述語を評価することを特徴とする請求項７５に記載のリソースチェ ッカ。 ７７．前記実行エンジンが、前記１つ若しくは複数のステートメントの選択され たステートメントが呼び出しされるコンポーネントに対する呼び出しであるか否 かを判定し、 前記実行エンジンが、前記選択されたステートメントが呼び出しされるコンポ ーネントに対する呼び出しである場合に、前記リソースの前記リソース状態に対 する前記呼び出されたコンポーネントの前記効果を評価するために、前記呼び出 されたコンポーネントの実行をエミュレートすることを特徴とする請求項７０に 記載のリソースチェッカ。 ７８．前記実行エンジンが、前記リソースが前記呼び出されたコンポーネントの エクスターナルと関連するか否かを判定すること、及び前記エクスターナルと関 連する前記リソースに対する前記コンポーネントの実行の前記効果を前記呼び出 されたコンポーネントのモデルから求めることによって、前記呼び出されたコン ポーネントの実行をエミュレートすることを特徴とする請求項７７に記載のリソ ースチェッカ。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ， ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者 ブッシュ、ウィリアム・アール アメリカ合衆国カリフォルニア州94402・ サンマテオ・レキシントンアベニュー 1739

Claims (1)

1. 【特許請求の範囲】 １．電子計算機用プログラムの１つ若しくは複数のステートメントからなるコン ポーネントのプログラミングエラーの検出方法であって、 （ａ）リソース状態を有するリソースに対する１つ若しくは複数の有効な状態 を定義する過程と、 （ｂ）前記１つ若しくはステートメントを通る制御流れ経路を通過する過程と 、 （ｃ）前記制御流れ経路に沿って前記１つ若しくは複数のステートメントの各 々に対して、（１）前記リソースの前記リソース状態に対する前記ステートメン トの効果を評価する過程と、（２）前記効果に基づいて前記リソース状態から前 記リソース状態の新たなリソース状態への遷移をモデル化する過程とを実施する 過程と、 （ｄ）前記新たな状態が、前記有効な状態のうちの１つの状態であるか否かを 判定する過程とを有することを特徴とするプログラミングエラーの検出方法。 ２．前記コンポーネントが関数からなることを特徴とする請求項１に記載の方法 。 ３．前記通過する過程が、 前記１つ若しくは複数のステートメントのうち選択されたステートメントが、 述語の値に基づいて前記制御流れ経路の一部を決定しているか否かを判定する過 程と、 前記制御流れ経路を決定するために前記述語を評価する過程とを有することを 特徴とする請求項１に記載の方法。 ４．前記述語を評価する過程が、 前記述語の前記値が未知であるか否かを判定する過程と、 前記述語に想定した値を代入する過程とを有することを特徴する請求 項３に記載の方法。 ５．前記述語を評価する過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する過程を更 に有することを特徴とする請求項４に記載の方法。 ６．前記述語を評価する過程が、 前記想定した値から前記述語の１つ若しくは複数のオペランドの各々の値を推 論する過程を更に有することを特徴とする請求項４に記載の方法。 ７．前記通過する過程が、 前記１つ若しくは複数のステートメントのうちの第２の選択されたステートメ ントが、前記第１の述語の前記１つ若しくは複数のオペランドからなる第２の述 語の第２の値に基づいて前記制御流れ経路の第２の部分を決定しているか否かを 判定する過程と、 前記第１の述語の前記１つ若しくは複数のオペランドの前記推論された各々の 値を用いて前記制御流れ経路の前記第２の部分を求めるために前記第２の述語を 評価する過程とを更に有することを特徴とする請求項６に記載の方法。 ８．前記過程（ｃ）の前記前記（１）が、 前記ステートメントが、呼び出されたコンポーネントに対する呼び出しである か否かを判定する過程と、 前記ステートメントが、呼び出されたコンポーネントに対する呼び出しである 場合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネン トの効果を評価するために、前記呼び出されたコンポーネントの実行をエミュレ ートする過程とを更に有することを特徴とする請求項１に記載の方法。 ９．前記呼び出されたコンポーネントの実行をエミュレートする前記過 程が、 前記リソースが、前記呼び出されたコンポーネントのエクスターナルに関連し ているか否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルと関連す る前記リソースに対する前記呼び出されたコンポーネントの実行の前記効果を判 定する過程とを有することを特徴とする請求項８に記載の方法。 １０．前記リソースが前記有効な状態のうちの何れでもないことをユーザに通知 する過程を更に有することを特徴とする請求項１に記載の方法。 １１．前記リソースの状態に対するその効果が、前記有効な状態の何れでもない 新たなリソース状態への遷移を引き起こすという効果である、前記ステートメン トを、ユーザに対して特定する過程を更に有することを特徴とする請求項１に記 載の方法。 １２．１つ若しくは複数のステートメントを有する電子計算機用プログラムのコ ンポーネントのプログラミングエラーの検出方法であって、 （ａ）リソース状態を有する１つのリソースに対する１つ若しくは複数の有効 な状態を定義する過程と、 （ｂ）各々が前記有効な状態の第１の状態から前記有効な状態の第２の状態へ の状態遷移である１つ若しくは複数の有効な状態遷移を定義する過程と、 （ｃ）前記１つ若しくは複数のステートメントを通る制御流れ経路を通過する 過程と、 （ｄ）前期制御流れ経路に沿った前記１つ若しくは複数のステートメントの各 々に対して、（１）前記リソースの前記リソース状態に対する前記ステートメン トの効果を評価する過程と、（２）前記効果に基づいて前記リソースの前記リソ ース状態の変化をモデル化する過程とを実行 する過程と、 （ｅ）前記変化が、前記有効な状態遷移のうちの１つではないことを検知する 過程とを有することを特徴とする方法。 １３．前記通過する過程が、 前記１つ若しくは複数のステートメントのうちの選択されたステートメントが 、述語の値に基づいて前記制御流れ経路の一部分を決定しているか否かを判定す る過程と、 前記制御流れ経路を決定するために、前記述語を評価する過程とを有すること を特徴とする請求項１２に記載の方法。 １４．前記述語を評価する前記過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を代入する過程とを有することを特徴とする請求項１３ に記載の方法。 １５．前記述語を評価する前記過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する過程を更 に有することを特徴とする請求項１４に記載の方法。 １６．前記述語を評価する前記過程が、 前記想定した値から、前記述語の１つ若しくは複数の要素の各々の値を推論す る過程を更に有することを特徴とする請求項１４に記載の方法。 １７．前記通過する過程が、 前記１つ若しくは複数のステートメントのうちの第２の選択されたステートメ ントが、前記第１の述語の前記１つ若しくは複数の要素を有する第２の述語の第 ２値に基づいて前記制御流れ経路の第２の部分を判定する過程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、 前記第２の述語を評価する過程とを更に有することを特徴とする請求項１６に記 載の方法。 １８．前記過程（ｄ）の前記過程（１）が、 前記ステートメントが、呼び出されたコンポーネントに対する呼び出しである か否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しである場 合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネント の前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミュ レートする過程とを有することを特徴とする請求項１２に記載の方法。 １９．前記呼び出されたコンポーネントの実行をエミュレートする前記過程が、 前記リソースが、前記呼び出されたコンポーネントのエクスターナルに関連す るか否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルに関連す る前記リソースに対する前記コンポーネントの前記実行の前記効果を求める過程 とを有することを特徴とする請求項１８に記載の方法。 ２０．前記リソース状態が前記有効な状態の何れでもないことをユーザに通知す る過程を更に有することを特徴とする請求項１２に記載の方法。 ２１．前記リソース状態に対するその効果が、前記有効な状態の何れでもない新 たなリソース状態への遷移を引き起こす効果である前記ステートメントを、ユー ザに対して特定する過程とを更に有することを特徴とする請求項１２に記載の方 法。 ２２．エクスターナルを含む電子計算機用プログラムのコンポーネントの振る舞 いのモデル化方法であって、 （ａ）前記エクスターナルに対して、エクスターナル状態を含む１つ 若しくは複数の有効な状態を定義する過程と、 （ｂ）前記コンポーネントの１つ若しくは複数のステートメントを有する制御 流れ経路を通過する過程と、 （ｃ）前記１つまたは複数のステートメントの各々に対して、（１）前記ステ ートメントの実行が、前記エクスターナルの前記エクスターナル状態に対する効 果を有するか否かを判定する過程と、（２）前記効果に基づいて前記エクスター ナル状態から前記エクスターナル状態の新たなエクスターナル状態への遷移をモ デル化する過程とを実行する過程と、 （ｄ）前記エクスターナルに対する前記コンポーネントの前記ステートメント の共通の効果を表すモデルを構築する過程とを有することを特徴とする電子計算 機用プログラムのコンポーネントの振る舞いのモデル化方法。 ２３．前記通過する過程が、 前記１つ若しくは複数のステートメントの内の選択されたステートメントが、 述語の値に基づいて前記制御流れ経路の一部を決定するか否かを判定する過程と 、 前記制御流れ経路を決定するために、前記述語を評価する過程とを有すること を特徴とする請求項２２に記載の方法。 ２４．前記述語を評価する過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を代入する過程とを有することを特徴とする請求項２３ に記載の方法。 ２５．前記述語を評価する前記過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する過程を更 に有することを特徴とする請求項２４に記載の方法。 ２６．前記述語を評価する前記過程が、 前記想定した値から、前記述語の１つ若しくは複数のコンポーネントの各々の 値を推論する過程を更に有することを特徴とする請求項２４に記載の方法。 ２７．前記通過する過程が、 前記１つ若しくは複数のステートメントのうちの第２の選択されたステートメ ントが、前記第１の述語の前記１つ若しくは複数の要素を有する第２の述語の第 ２の値に基づいて前記制御流れ経路の第２の部分を決定するか否かを判定する過 程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語を 評価する過程とを更に有することを特徴とする請求項２６に記載の方法。 ２８．前記述語を評価する前記過程が、 前記想定した値から、前記エクスターナルの前記状態に関する情報を推論する 過程を更に有することを特徴とする請求項２４に記載の方法。 ２９．前記過程（Ｃ）の前記過程（１）が、 前記ステートメントが、呼び出されたコンポーネントに対する呼び出しである か否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しである場 合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネント の前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミュ レートする過程とを有することを特徴とする請求項２２に記載の方法。 ３０．前記呼び出されたコンポーネントの実行をエミュレートする前記過程が、 前記リソースが、前記呼び出されたコンポーネントのエクスターナル に関連しているか否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルに関連す る前記リソースに対する前記コンポーネントの実行の前記効果を求める過程とを 有することを特徴とする請求項２９に記載の方法。 ３１．（ｅ）１つ若しくは複数のステートメントの第２の集合を有する第２の制 御流れ経路を通過する過程と、 （ｆ）前記１つ若しくは複数のステートメントからなる第２の集合の各々のステ ートメントに対し、（１）前記ステートメントの実行が、前記エクスターナルの 前記エクスターナル状態に対する効果を有するか否かを判定する過程と、（２） 前記効果に基づき、前記エクスターナル状態から前記エスクターナル状態の第２ の新たなエクスターナル状態への遷移をモデル化する過程とを実行する過程と、 （ｇ）前記第１の新たなエクスターナル状態と前記第２の新たなエタスターナ ル状態とから、前記エスクターナルの組合せエクスターナル状態を形成する過程 とを更に有することを特徴とする請求項２２に記載の方法。 ３２．前記通過する過程が、 前記１つ若しくは複数のステートメントのうちの選択されたステートメントが 、述語の値に基づいて前記第２の制御流れ経路の一部を決定するか否かを判定す る過程と、 前記第２の制御流れ経路を決定するために、前記述語を評価する過程とを有す ることを特徴とする請求項３１に記載の方法。 ３３．前記述語を評価する過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を代入する過程を有することを特徴とする請求項３２に 記載の方法。 ３４．前記述語を評価する前記過程が、 前記想定した値から前記リソースの前記状態に関する情報を推論する過程を更 に有することを特徴とする請求項３３に記載の方法。 ３５．前記述語を評価する過程が、 前記想定した値から、前記述語の１つ若しくは複数の要素の各々の値を推論す る過程を更に有することを特徴とする請求項３３に記載の方法。 ３６．前記述語を評価する過程が、 前記想定した値から、前記エクスターナルの前記状態に関する情報を推論する 過程を更に有することを特徴とする請求項３３に記載の方法。 ３７．前記通過する過程が、 前記１つ若しくは複数のステートメントの第２の選択されたステートメントが 、前記第１の述語の前記１つ若しくは複数の要素を有する第２の述語の第２の値 に基づいて前記制御流れ経路の第２の部分を決定するか否かを判定する過程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語を 評価する過程を更に有することを特徴とする請求項３５に記載の方法。 ３８．前記過程（ｆ）の前記過程（１）が、 前記ステートメントが、呼び出されたコンポーネントに対する呼び出しである か否かを判定する過程と、 前記ステートメントが前記呼び出されたコンポーネントに対する呼び出しであ る場合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネ ントに対する前記効果を評価するために、前記呼び出されたコンポーネントの実 行をエミュレートする過程とを有することを特徴とする請求項３１に記載の方法 。 ３９．前記呼び出されたコンポーネントの実行をエミュレートする過程が、 前記リソースが、前記呼び出されたコンポーネントのエクスターナルと関連す るか否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルと関連す る前記リソースに対する前記コンポーネントの実行の前記効果を求める過程とを 有することを特徴とする請求項３８に記載の方法。 ４０．前記エクスターナルの前記組合せ状態から、前記コンポーネントの前記振 る舞いのモデルを導き出す過程を更に有することを特徴とする請求項３１に記載 の方法。 ４１．前記コンポーネントの前記振る舞いの前記モデル内に、前記エクスターナ ルの前記状態の１つ若しくは複数の遷移を指示する情報を含める過程を更に有す ることを特徴とする請求項４０に記載の方法。 ４２．前記エクスターナルに対する前記第１のコンポーネントの実行の効果を決 定するために、前記第１のコンポーネントへの呼び出しを含む前記電子計算機用 プログラムの呼び出しコンポーネントを分析する間に、前記モデルを用いる過程 を更に有することを特徴とする請求項２２に記載の方法。 ４３．リソースの利用を指示する電子計算機用プログラムのコンポーネントの振 る舞いをモデル化する方法であって、 （ａ）リソース状態を有する前記リソースに対する１つ若しくは複数の有効な 状態を定義する過程と、 （ｂ）前記コンポーネントの１つ若しくは複数のステートメントを有する制御 流れ経路を通過する過程と、 （ｃ）前記１つ若しくは複数のステートメントの各々に対して、（１）前記ス テートメントの前記実行が、前記リソースの前記リソース状態に 対する効果を有するか否かを判定する過程と、（２）前記効果に基づいて前記リ ソース状態から前記リソース状態の新たなリソース状態への遷移をモデル化する 過程とを実行する過程と、 （ｄ）前記リソースに対する前記コンポーネントの前記ステートメントの共通 の効果を表すモデルを構築する過程とを有することを特徴とする方法。 ４４．前記通過する過程が、 前記１つ若しくは複数のステートメントの選択されたステートメントが、述語 の値に基づいて前記制御流れ経路の一部を決定するか否かを判定する過程と、 前記制御流れ経路を決定するために、前記述語を評価する過程とを有すること を特徴とする請求項４３に記載の方法。 ４５．前記評価する過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を代入する過程とを有することを特徴とする請求項４４ に記載の方法。 ４６．前記述語を評価する過程が、 前記想定した値から、前記リソースの前記状態に関する情報を推論する過程を 更に有することを特徴とする請求項４５に記載の方法。 ４７．前記述語を評価する過程が、 前記想定した値が、前記述語の前記１つ若しくは複数の要素の各々値を推論す る過程を更に有することを特徴とする請求項４５に記載の方法。 ４８．前記通過する過程が、 前記１つ若しくは複数のステートメントのうちの第２の選択されたステートメ ントが、前記第１の述語の１つ若しくは複数の前記要素を第２の述語の第２の値 に基づいて前期制御流れ経路の第２の部分を決定する か否かを判定する過程と、 前記第１の述語の前記１つ若しくは複数の要素の前記推論された各々の値を用 いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語を 評価する過程とを更に有することを特徴とする請求項４７に記載の方法。 ４９．前記過程（ｃ）の前記過程（１）が、 前記ステートメントが、前記呼び出されたコンポーネントに対する呼び出しで あるか否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しである場 合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネント の前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミュ レートする過程とを有することを特徴とする請求項４３に記載の方法。 ５０．前記呼び出されたコンポーネントの実行をエミュレートする過程が、 前記リソースが、呼び出されたコンポーネントのエクスターナルに関連するか 否かを判定する過程を、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルと関連す る前記リソースに対する前記コンポーネントの実行の前記効果を決定する過程を 有することを特徴とする請求項４９に記載の方法。 ５１．（ｅ）１つ若しくは複数のステートメントの第２の集合を有する第２の制 御流れ経路を通過する過程と、 （ｆ）前記１つ若しくは複数のステートメントからなる前記第２の集合の各ス テートメントに対して、（１）前記リソースの前記リソース状態に対する前記ス テートメントの効果を評価する過程と、（２）前記効果に基づいて、前記リソー スのステートメントから前記リソースの第２ の新たなリソースのステートメントへの遷移をモデル化する過程とを実行する過 程と、 （ｇ）前記第１の新たなリソースのステートメントと前記第２の新たなリソー スのステートメントとから、前記リソースの共通のリソースのステートメントを 形成する過程とを更に有することを特徴とする請求項４３に記載の方法。 ５２．前記通過する過程が、 前記１つ若しくは複数のステートメントの選択されたステートメントが、述語 の値に基づいて前記制御流れ経路の一部を決定するか否かを判定する過程と、 前記制御流れ経路を決定するために、前記述語を評価する過程とを有すること を特徴とする請求項５１に記載の方法。 ５３．前記述語を評価する過程が、 前記述語の前記値が未知の値であるか否かを判定する過程と、 前記述語に想定した値を代入する過程とを有することを特徴とする請求項５２ に記載の方法。 ５４．前記述語を評価する前記過程が、 前記想定した値から前記リソースが前記状態に関する情報を推論する過程を更 に有することを特徴とする請求項５３に記載の方法。 ５５．前記述語を評価する前記過程が、 前記想定した値から、前記述語の前記１つまたは複数の要素の各々の値を推論 する過程を更に有することを特徴とする請求項５３に記載の方法。 ５６．前記通過する過程が、 前記１つまたは複数のステートメントのうちの第２の選択されたステートメン トが、前記第１の述語の前記１つまたは複数の要素を有する第 ２の述語の第２の値に基づいて、前記制御流れ経路の第２の部分を決定するか否 かを判定する過程と、 前記第１の述語の前記１つまたは複数の要素の前記推論されたおのおのの値を 用いて、前記制御流れ経路の前記第２の部分を決定するために、前記第２の述語 を評価する過程とを更に有することを特徴とする請求項５５に記載の方法。 ５７．前記過程（ｇ）の前記過程（１）が、 前記ステートメントが、呼び出されたコンポーネントに対する呼び出しであ るか否かを判定する過程と、 前記ステートメントが呼び出されたコンポーネントに対する呼び出しである場 合、前記リソースの前記リソース状態に対する前記呼び出されたコンポーネント の前記効果を評価するために、前記呼び出されたコンポーネントの実行をエミュ レートする過程を有することを特徴とする請求項５１に記載の方法。 ５８．前記呼び出されたコンポーネントの実行をエミュレートする過程が 前記リソースが前記呼び出されたコンポーネントのエクスターナルと関連して いるか否かを判定する過程と、 前記呼び出されたコンポーネントのモデルから、前記エクスターナルの関連す る前記リソースに対する前記コンポーネントの前記効果を判定する過程とを有す ることを特徴とする請求項５７に記載の方法。 ５９．前記リソースの前記組み合わせ状態から、前記コンポーネントの前記振る 舞いのモデルを導き出す過程を更に有することを特徴とする請求項５１に記載の 方法。 ６０．前記コンポーネントの前記振る舞いの前記モデルに、前記リソースの前記 状態の１つまたは複数の遷移を指示する情報を包含させる過程 を更に有することを特徴とする請求項５９に記載の方法。 ６１．前記リソースの前記第１のコンポーネントの実行の前記効果を求めるため に、前記第１のコンポーネントに対する呼び出しを含む前記電子計算機用プログ ラムのコーリングコンポーネントを解析する間に、前記モデルを用いる過程を更 に有することを特徴とする請求項４３に記載の方法。 ６２．電子計算機用プログラムのコーリングコンポーネントの実行の項目に対す る効果の解析方法であって、 前記コーリングコンポーネントが、エクスターナルからなる前記項目を有する 呼び出されたコンポーネントに対する呼び出しを含むか否かを判定する過程と、 前記呼び出されたコンポーネントの前記実行の前記呼び出されたコンポーネン トの１つ若しくは複数の前記エクスターナルに対する効果を記述しているコンポ ーネントモデルから、前記呼び出されたコンポーネントの実行の前記項目の前記 効果を判定する過程とを有することを特徴とする電子計算機用プログラムのコー リングコンポーネントの実行の項目に対する効果の解析方法。 ６３．前記項目が状態を有し、 前記呼び出されたコンポーネントの実行の前記項目に対する効果を判定する過 程が、前記呼び出されたコンポーネントによって指示された前記項目の前記状態 の変化を判定する過程を有することを特徴とする請求項６２に記載の方法。 ６４．前記呼び出されたコンポーネントが、前記項目の前記状態に実施されるべ き１つ若しくは複数のオペレーションを特定することによって、前記項目の前記 状態の変化を指示することを特徴とする請求項６３に記載の方法。 ６５．前記呼び出されたコンポーネントが、有効な状態から無効な状態への前記 項目の前記状態の遷移を指示しているか否かを判定する過程を更に有することを 特徴とする請求項６３に記載の方法。 ６６．前記呼び出されたコンポーネントが、第１の有効な状態から第２の有効な 状態への遷移以外の前記項目の前記状態の遷移を指示しているか否かを判定する 過程を更に有することを特徴とする請求項６３に記載の方法。 ６７．電子計算機用プログラムのコンポーネントのプログラミングエラーの検出 方法であって、 前記コンポーネントの１つ若しくは複数のステートメントによってその利用が 指示されているリソースが、１つ若しくは複数のステートメントの何れかの中に あるか否かを検出する過程と、 前記コンポーネントが、前記リソースが前記１つ若しくは複数のステートメン トの特定のステートメントのなかにあることを要求する第１のステートメントを 含むことを検知し、かつ、前記第１のステートメントが、前記コンポーネントを 通過する制御流れ経路において、その実行より前記リソースが前記特定の状態に あることが確実となる第２のステートメントによって先行されていないことを検 知する過程とを有することを特徴とする電子計算機用プログラムのコンポーネン トのプログラミングエラーの検出方法。 ６８．前記１つ若しくは複数の状態が、確定的にアロケートされた状態と、確定 的にアロケートされていない状態とを有することを特徴とする請求項６７に記載 の方法。 ６９．前記特定の状態が、前記確定的にアロケートされた状態からなることを特 徴とする請求項６８に記載の方法。 ７０．電子計算機用プログラムのコンポーネントのリソースのリークの 検知方法であって、前記コンポーネントは、１つ若しくは複数のリソースの利用 を指示するステートメントと、１つ若しくは複数のエクスターナルとを含み、 前記検出方法が、 前記１つ若しくは複数のリソースのうちのいずれのリソースが前記１つ若しく は複数のエクスターナルの何れかによって到達されるか否かを判定する過程と、 前記エクスターナルによって到達されない前記リソースが、前記コンポーネン トの実行の終了時にアロケートさけた状態にあるか否かを判定する過程とを有す ることを特徴とする方法。 ７１．前記１つ若しくは複数のリソースのいずれが到達されるかを判定する前記 過程が、 前記コンポーネントのエクスターナルが、前記リソースへ到達するための項目 を含む集群に含まれているか否かを判定する過程を有することを特徴とする請求 項７０に記載の方法。 ７２．電予計算機用プログラムのコンポーネントのデータフロー解析の実行方法 であって、 前記コンポーネントのステートメントが、述語の値に基づいて制御を遷移させ る１つ若しくは複数の要素を有する条件付き分岐ステートメントからなるか否か を判定する過程と、 前記述語が第１の値を有すると仮定する過程と、 前記第１の値から、前記述語の前記１つ若しくは複数の要素のおのおのの値を 推論する過程とを有することを特徴とする方法。 ７３．前記述語の前記第１の値に基づいて、前記コンポーネントを通って、前記 条件付けられた分岐ステートメントを有する制御流れ経路を通過させる過程を更 に有することを特徴とする請求項７２に記載の方法。 ７４．前記コンポーネントの第２のステートメントが、前記第１の述語の前記１ つ若しくは複数の要素を含むと共に第２の述語の第２の値に基づいて制御を遷移 させる第２の条件付けられた分岐ステートメントであるか否かを判定する過程と 、 前記第１の述語の前記１つ若しくは複数の要素の前記推論されたおのおのの値 から前記第２の値を求める過程とを更に有することを特徴とする請求項７２に記 載の方法。 ７５．電子計算機用プログラムの１つ若しくは複数のステートメントを有するコ ンポーネントのプログラミングエラーを検出するリソースチェッカであって、 リソース状態を有するリソースに対して１つ若しくは複数の有効な状態を定義 するリソース振る舞いモデルと、 前記１つ若しくは複数のステートメントを通る制御流れ経路を通過すると共に 前記１つ若しくは複数のステートメントのおのおのが前記リソースの前記リソー ス状態に対する各々の効果を有するか否かを判定する実行エンジンと、 前記１つ若しくは複数のステートメントの各々の前記効果に基づく前記リソー ス状態から新たなリソース状態への遷移をモデル化し、かつ前記新たな状態が前 記有効な状態のうちのいずれかの状態であるか否かを検出する状態マシンとを有 することを特徴とするリソースチェッカ。 ７６．前記コンポーネントが関数からなることを特徴とする請求項７５に記載の リソースチェッカ。 ７７．前記実行エンジンが、前記１つ若しくは複数のステートメントのうちの選 択されたステートメントが述語の値に基づく前記制御流れ経路の一部を決定する か否かを判定し、かつ前記制御流れ経路を決定するた めに前記述語を評価することを特徴とする請求項７５に記載のリソースチェッカ 。 ７８．前記実行エンジンが、前記述語の前記値が未知の値であるか否かを判定し 、かつ前記述語に想定した値を代入することによって前記述語を評価することを 特徴とする請求項７７に記載のリソースチェッカ。 ７９．前記実行エンジンが、前記想定した値から、前記リソースの前記状態に関 する情報を推論することを特徴とする請求項７８に記載のリソースチェッカ。 ８０．前記実行エンジンが、前記想定した値から、前記述語の１つ若しくは複数 の要素の各々の値を推論することを特徴とする請求項７８に記載のリソースチェ ッカ。 ８１．前記実行エンジンが、前記１つ若しくは複数のステートメントの第２の選 択されたステートメントが前記第１の述語の１つ若しくは複数の前記要素を有す る第２の述語の第２の値に基づいて前記制御フローバスの第２の部分を決定して いるか否かを判定して前記制御流れ経路を通過し、 前記実行エンジンが、前記第１の述語の前記１つ若しくは複数の要素の前記推 論された各々の値を用いて前記制御流れ経路の前記第２の部分を決定するために 前記第２の述語を評価することを特徴とする請求項８０に記載のリソースチェッ カ。 ８２．前記実行エンジンが、前記１つ若しくは複数のステートメントのうちの選 択されたステートメントが呼び出しされるコンポーネントに対する呼び出しであ るか否かを判定し、 前記実行エンジンが、前記選択されたステートメントが呼び出されたコンポー ネントに対する呼び出しからなる場合に、前記リソースの前記リソース状態に対 する前記呼び出されたコンポーネントの前記効果を評 価するために前記呼び出されたコンポーネントの実行をエミュレートすることを 特徴とする請求項７５に記載のリソースチェッカ。 ８３．前記実行エンジンが、前記リソースが前記呼び出されたコンポーネントの エクスターナルと関係しているか否かを判定し、かつ前記呼び出されたコンポー ネントのモデルから前記リソースの前記エクスターナルと関係する前記コンポー ネントの実行の効果を求めることによって、前記呼び出されたコンポーネントの 実行をエミュレートすることを特徴とする請求項８２に記載のリソースチェッカ 。