JP4430043B2 - A computer method for checking program component errors - Google Patents

Abstract

An error detection mechanism for detecting programing errors in a computer program. A component of the computer program, e.g., a procedure or function of the computer program, is analyzed to determine the effect of the component on resources used by the computer program. A component is analyzed by traversing the computer instructions, i.e., statements, of the component and tracking the state of resources used by the component as affected by the statements of the component. Each resource has a prescribed behavior represented by a number of states and transition between states. Violations in the prescribed behavior of a resource resulting from an emulated execution of the statements of the component are detected and reported as programming errors. Resources used by two or more components are modelled by modelling externals of the components. The effect of execution of a component on externals and resources of the component is determined by traversing one or more possible control flow paths through the component and tracking the use of each external and resource by each statement of each control flow path. Once the effect of execution of a component on externals and resources of the component is determined, a model of the component is created and used to model externals and resources of other components which invoke the modelled component.

Description

  Computer Process Resource Modeling Method and Apparatus Appendix A Appendix A, which is part of this disclosure, is a list of computer programs and associated data in one embodiment of the present invention that is described in more detail below.

  Part of the disclosure of this patent document contains material subject to copyright protection. This copyright owner does not object to any reproduction of this patent document or patent disclosure by anyone who appears in the patent file or record of the Patent and Trademark Office, but otherwise Is reserved for copyright.

  The present invention relates to the analysis of computer programs. In particular, it relates to detecting programming errors in a computer program through an analysis of the use of resources defined by the computer program.

Some existing programming error detection methods detect violations in a computer instruction protocol that a particular program should follow. Such a program error detection method is called "static checking", which is a context in which the grammar of computer instructions (or "statements") in a computer program results from the execution of those statements. This is because the analysis is performed outside (context). The term "statement" is used herein, due to Herbert Schildt "annotated version of ANSI C standard (Osborne McGraw-Hill 1990)" ( hereinafter, C standard referred to as) has been reprinted as "American National Standard for ProgrammingLanguages-- C (American National Standards Institute / International Organization for Standardization ANSI / ISO 9899-1990) "as used in the meaning defined in Section 6.6. Briefly, in the context of C, a statement is a computer instruction that is not a declaration. In other words, a statement is any expression or instruction that instructs a computer to perform one or more processing steps. The static check method in the context of C language includes (i) ensuring that there are no two variables with the same name in the computer program, (ii) “while” preceded by each “break” statement, Including verifying that it corresponds to a “for” or “switch” statement, and (iii) verifying that the operator is applied to the appropriate operands. For the static check method, see, for example, Alfred V.A. Aho et al., “ Compilers (Addison Wesley 1988)”.

Some existing static checking methods, commonly referred to as “data flow analysis” techniques, analyze the flow of data in a program to detect programming errors. Such an analysis can be used to detect control flow information by, for example, arranging statements and loop statements in order to detect inappropriate use of data objects such as using a variable before a value is assigned to a variable. Take advantage of. A control flow in a computer program is a specific order in which computer instructions of the computer program are executed in a computer process defined by the computer program. Computer programs and processes and their relationships will be described in more detail later. Data flow techniques are described by Beizer in “ Software Testing Techniques , (1990) pp. 145-172”.

  Existing static checking methods have the disadvantage that it is impossible to track the use of resources through several individual components of a computer program, such as the functions that together form a computer program. For example, a variable may be initialized in a first function and used in calculations in a second subsequent function. By simply analyzing the computer instructions of the second function, the variable appears to be used before it is initialized, which can be erroneously signaled as an error. Furthermore, existing static checking methods are static in nature and do not take into account specific data values associated with specific data objects. Static analysis is limited to being able to determine without considering the dynamic effects of program execution. Beizer describes some areas where static analysis is inappropriate. They include arrays, particularly dynamically calculated indicators and dynamically allocated arrays; records and pointers; files; and alternate state tables. These represent different types of different semantics in the same program.

  The static checker does not detect an error including an index that is calculated to form an address or an array that is calculated corresponding to a dynamically allocated memory. The calculated address and index are respectively the address and index calculated during the execution of the computer process. The reason that static checkers do not detect such errors in a computer program is that investigating such errors usually involves determining the exact value of the calculated address and index, which includes runtime This is because it includes consideration of the behavior of the computer program, that is, consideration as a computer process.

  Static checkers also do not detect errors that involve the use of resources that are suspected of being successfully allocated or the use of resources whose state is determined by the value of a variable or other data object. In C, it is questionable whether resources (eg, dynamically allocated memory or files) are allocated successfully. In other words, the function for allocating resources ends normally even if resource allocation fails. Whether or not the allocation was successful is determined by comparing the return value item of the function (a pointer to the allocated resource) with an invalid value (eg NULL), but the static checker considers the behavior of the called function Instead, it verifies only that the grammar of the call to the called function conforms to the grammar defined in the specific computer language. Thus, the static checker does not detect errors that involve the use of resources that are suspected of being successfully allocated.

  As mentioned above, the static checker does not consider the behavior of the called function. Therefore, it is impossible to verify the use of resources across multiple functions. For example, if a first function allocates a resource, a second function uses the resource, and a third function deallocates the resource, the first, second, and second Proper use of resources cannot be verified by statically examining any of the three functions alone or a single function that makes all three function calls.

  If error detection techniques are used that do not make full use of information about the behavior of the computer program at run time, errors detected by such techniques are either under-detected or over-detected. For example, if a function receives a pointer that specifies a resource (eg, a file) to be allocated as a parameter and uses that parameter without comparing it to an invalid pointer, the function may contain an error. Whether the function contains an error depends on various situations that are not known within the context of the function. For example, if the pointer is verified to be a valid pointer before the function is called, the function does not contain an error. Notifying the use of the pointer as an error confuses the analysis of the function with an erroneous error notification and makes the error excessive. Notifying an error in the analysis of a large program at all would bother the program developer at best, and would otherwise make the computer program analysis useless. If the pointer is not checked for validity before calling the function, failure to notify the error will cause the computer program to abruptly abort at run time, resulting in data structure corruption or loss of valid data. It will not be detected.

One drawback of the static check method that does not take into account the dynamic behavior of the computer program is the notification of obvious but "false" errors. That is, to notify an error resulting from a computer instruction that cannot be controlled.
In functions where the control flow path depends on specific values associated with specific data structures and program variables, the control flow is determined without considering the values associated with these data structures and variables. It is not possible. Also, the values associated with these data structures and variables generally cannot be determined without considering the behavior of the function at runtime. As a result, instructions that are not executed or instructions that are executed only under certain conditions are generally assumed to always be executed by a static checker.

Another type of existing programming error detection technique is called program verification. In program verification, a computer program is treated as a formal mathematical object. Errors in the computer program are detected by using theoretical mathematics to verify or fail to verify certain characteristics of the computer program. One characteristic that is generally attempted to be verified is that given a given input, a computer process defined by a computer program produces a given output. If the verification fails, the computer program contains a programming error. Such a program verification technique is described in, for example, Eric C.I. R. “ A Practical Theory of Programming , (Verlag 1993)” by Hehner et al. And “ Verifiable Programming , (Prentice Hall 1992)” by Ole-Johan Dahl.

Program verification techniques are limited in at least two ways.
That is, (i) only the characteristics of a computer program that can be expressed and automatically verified using formal logic can be verified. (Ii) The computer program developer formalizes the characteristics of a computer program. Must be clearly expressed. Formally expressing the characteristics of a computer program is extremely difficult in any case and almost impossible with large programs. Therefore, commercially successful products using program verification techniques are very rare.

  In another type of programming error detection technique, a computer program is executed, thus forming a computer process and monitoring the behavior of the computer process. Such a program error detection technique is called “runtime checking” because the analysis of the computer program is done during the execution of the program. Some runtime check techniques automatically insert computer instructions into a computer program, and when the computer program is executed, the inserted computer instructions are executed to indicate the status of computer program variables and resources. There is something to be done. Such an error detection technique is described in US Pat. No. 5,193,180 to Hastings.

  The runtime check can usually detect errors such as memory leaks or an index of an array that has entered a prohibited area. Examples of runtime checks include “Purify” available from “Pure Software Inc.”, Sunnyvale, Calif., And “Parasoft Corporation” available from “Parasoft Corporation”, Pasadena, Calif. There is. “Purify” inserts computer instructions for monitoring a computer program after the computer is compiled into object code format. “Insight” inserts computer instructions to monitor the computer program before it is compiled, that is, when the computer program is still in source code form.

  Runtime checks are generally limited to those that can be determined by actually executing the computer instructions of the computer program using the actual specific inputs. The runtime checker method does not consider the entire path of the control flow of the computer program, but only considers the path corresponding to the specific input given to the computer program at runtime. In general, it is not practical to allow a computer process formed by the execution of computer instructions in a computer program to go through all possible control flow paths. To do so, it is necessary for the programmer to anticipate all events that can occur during the execution of the computer instructions of the computer program, and to generate or emulate all combinations of such event occurrences. It is.

  In addition, runtime checks can only be used when the computer program is complete. In runtime checking, it is impossible to analyze a function before it is incorporated into a complete program. This is because the function must be executed for analysis. Thus, to analyze functions using runtime checks, (i) all functions of a computer program are developed and combined to form a computer program before analyzing any of those functions. Or (ii) a special test program incorporating the function must be developed. Therefore, the well-known top-down programming is a good way to develop complex computer programs that design, produce and test individual functions before incorporation into a finished computer program. I'm not familiar.

  US Pat. No. 5,253,158 (hereinafter referred to as “Suzuki”) issued to Suzuki et al. Describes the execution time of software (sequencer software) to be used to control the operation of automated equipment. An apparatus for performing a check is disclosed. According to "Suzuki", sequencer software can be tested without using automated equipment. In the invention of “Suzuki”, information relating to the operating environment of software, information relating to automated device characteristics, and information relating to test cases to be executed are stored in the storage device (FIG. 1). Next, in the “Suzuki” invention, the operation of an automated device controlled by sequencer software is simulated, and a simulated result is obtained (lines 54 to 59 in the first column). The simulation of the "Suzuki" invention requires execution of sequencer software (column 4, line 50). The execution time check device disclosed in "Suzuki" has been the subject of the limits of analysis of execution time, as explained so far.

  Fu Ting Chang and Tsong Yue Chen are “AIDA-A Dynamic Data Flow Anomaly Detection System for Pascal Programs, Software, Practice and Expert Experience, page 1987, page 2 of the third program” A dynamic data flow analysis system is described. AIDA (automated instruction system) analyzes a grammatically corrected Pascal program and converts this program into an instruction program. The instruction program checks the format of the procedure call for initializing, following, or chucking the state of variables inserted in the original Pascal source code. During program execution, AIDA detects data flow anomalies and programming errors such as uninitialized variables, incorrect use of variables, incorrect classification of variables, and unintentional destruction of defined variables. . AIDA is the subject of limiting execution time analysis, as described above.

  What is needed is to consider the dynamic behavior of a computer program and automatically consider almost all control flow paths of the computer program, so that the computer program programmer can convert the computer program into another form, for example mathematical It is a programming error detection technique that does not need to be expressed in a form. What is further needed is a programming error detection technique that analyzes individual components of a program taking into account the behavior of that component during execution. What is further needed is a programming error detection technique that takes into account the behavior of components that are triggered to execute by the computer program component being analyzed.

In order to solve such a problem, the present invention is a method in a computer for checking an error of a program component having a plurality of statements, the program component constituting a computer program, The computer includes storage means for storing the program component, information processing means, and a resource to be processed by the program component, which is assigned to and released from one or more program components. Executing the plurality of statements of the program component stored in the storage means by the information processing means, and the resource generated by executing the plurality of statements by the information processing means And a determining step by the information processing means whether the program component or an error by a change of state to determine whether a change to a predetermined, the step of determining, by said program component The behavior of the resource used is modeled, and the occurrence of an error in the program component is determined by analyzing the program component by detecting a state violation that may occur in the resource, The determination of the occurrence of the error is performed when the statement included in the program component is executed using information on a correspondence relationship between the modeled behavior of the resource and the statement included in the program component. Said correspondence Using the information for estimating the following behavior, and characterized in that to determine whether an error occurs due to behaviors that the estimation.

  According to one aspect of the present invention, a computer program is analyzed by modeling behavior of resources used by the computer program and detecting state violations that may occur in those resources. An error is detected. A resource is modeled based on a resource state and a resource state transition (change) that represents the behavior of the resource. The computer instructions of the computer program are examined dynamically. That is, the dynamic behavior of the computer instruction is determined, and the state of the resource is changed according to the dynamic behavior of the computer instruction.

  Each component of the computer program is analyzed individually. Resources whose usage spans multiple components, eg, resources allocated by the first component, used by the second component, and released by the third component, are analyzed by modeling each component's external Is done. The two components of the computer program communicate with each other through each component's external. For example, information about the resource allocated by the first component is communicated to the second component that uses the resource through the external of the first and second components. By analyzing the behavior of each component with respect to that component's external, appropriate modeling of resources across multiple components is made.

  As each component is analyzed, the impact of component execution on each external of that component is determined. A component model is generated from the component analysis. The component model describes the impact of the component's execution on each external of the component, with respect to each change in the external state and the introduction of new resources associated with any of the component's externals. It is. The number of effects that the execution of the modeled component has and the externals that are affected are arbitrary, and these effects are expressed in the external composite state. The generated component model can be used to analyze other components that trigger the execution of the modeled component.

  According to the present invention, errors in a computer program are detected by modeling the resources used by the computer program and detecting state violations that can occur in those resources.

  First, the resource is modeled by simulating the behavior of the resource with respect to the resource state and state transition. Each computer instruction of the computer program is analyzed, and the state of the resource is changed based on the influence of execution of the computer instruction on the resource. A state violation, that is, an invalid state and an invalid state transition in the resource state are detected and notified as a program error. In this way, error detection according to the present invention takes into account the behavior of a computer process defined by a computer program, thereby overcoming many of the limitations of the prior art static check method.

  Each resource has a predetermined behavior, which can be described in terms of valid states and valid transitions between those states. The source of errors in a computer program is often that the computer program developer does not know the predetermined behavior of the resource. A state violation occurs when a computer instruction in a computer program instructs the computer to use a resource that violates a predetermined behavior of the resource. An example of a state violation is, for example, reading a record from a file after closing the file when the file must be opened for reading according to the predetermined behavior of the file.

  The computer 100 (FIG. 1) includes a central processing unit (CPU) 102, a memory 104, and an input / output circuit (I / O circuit) 106, all of which are connected to each other via a bus 108. ing. The memory 104 may include any type of memory including secondary storage devices such as magnetic disks, random access memory (RAM), and read only memory (ROM). The CPU 102 reads the computer process 110 from the memory 104 and executes it. Computer process 110 has access to library function 112, dynamically allocated memory 114, and second computer process 116. The I / O circuit 106 includes drivers 106A, 106B, 106C, 106D, and 106E, which are a video monitor 118, a secondary storage device 120, a network 126, a pointing device (such as a mouse 122), and a keyboard, respectively. 124 is driven and controlled.

  As used herein, a resource is part of a computer system used by a computer process and generally must be allocated before use and released or freed after use. Examples of resources include global memory, files, windows, menus, and dialogs. Computer process 110 resources include, for example, dynamically allocated memory 114, computer process 116, and magnetic disk 120.

  In this specification, a computer process is a series of steps executed by a computer. A computer program is a series of instructions that can be executed by a computer. Processes are defined by the instructions of a computer program, and when they are executed by a computer, a computer process is formed. Therefore, in order to model the behavior of the computer process 110, a computer program defining the computer process 110 is analyzed.

An analysis computer program at the function level is usually a combination of already developed components and newly developed code. As used herein, “code” refers to source code, ie, a series of computer instructions in a form that is understandable to humans, and / or object code, ie, a series of computer instructions in a form that is understandable to a computer. A component of a computer program is a collection of computer instructions and / or data structures that have already been developed to execute a particular partial process and that have been tested to be executed faithfully. A partial process is one or more steps in a computer process, that is, a part of a computer process. Computer program developers use such components to execute specific sub-processes, and usually trust that component and expect it to function as it is defined at runtime. Such components may include requests for execution of components already developed by the developer or commercially available components, ie calls. In this way, duplication of work in computer program development is avoided.

  New computer programs are usually developed by combining developed components and connecting these components together using newly written computer instructions. Such a combination and interconnection results in a new component or new computer program that can be used by other components or computer programs. A component of a computer program defines a partial process of the computer process defined by the computer program. Each sub-process of a computer process can change the state of resources used by that computer process. Therefore, in order to appropriately analyze the state and state transition of a resource used by a certain computer process, it is necessary to confirm the influence of the execution of the partial process defined by the component of the computer program on the state of the resource. For example, assigned in a first partial process defined by a first component, used in a second partial process defined by a second component, and in a third partial process defined by a third component. In order to properly analyze the use of the resources to be released, it is necessary to analyze the effects on the resources of the first, second, and third partial processes.

  The computer program may be written in any of various computer languages. A typical computer language is procedural. In a procedural language, computer instructions of a computer program are organized to form components, which are often referred to as procedures, or “functions”. They are each designed to execute a specific partial process when executed. Examples of procedural languages include C, Ada, Pascal, Fortran, and Basic. Procedural languages include object-oriented languages, such as C ++ and SmallTalk. In an object-oriented computer language, functions and data structures are combined to form objects, and these objects are further organized to form components known as “classes”.

  Some computer languages are graphic-based, in which instructions are represented as graphic images that are displayed on a computer screen. The programmer links the graphic images to form a computer program. For example, “Microsoft Visual Basic”, available from Microsoft Corporation of Redmond, Wash., Is such a graphics-based computer language. Computer languages include the “Microsoft Word Basic” computer language for the “Microsoft Word” word processor software available from Microsoft Corporation, and available from Lotus Development Corporation of Cambridge, Massachusetts. Some "Lotus 1-2-3" macro languages for spreadsheet software such as "Lotus 1-2-3" are intended for specific software products. The present invention is applicable to any computer language, ie any computer instruction protocol in which resources are used. Although the source code computer instruction protocol has been described above, it should be understood that what is disclosed herein is equally applicable to object code form computer instructions. In the exemplary embodiment shown below, the computer language to be analyzed is the well-known C language described in the C standard.

  A computer program written in C language is usually divided into several functions. When executed, the function receives zero or more parameters as input and may generate one returned item as output, but may not generate a return item. These parameters and return value items are data structures, include data accessible by the function, and are stored in a memory such as memory 104, for example. An example of a function defined in C language is shown later in computer code excerpt (1).

  In the exemplary embodiment described herein, each function in the computer program is analyzed individually. A function is analyzed by modeling the usage and changes of the function's resources, escalators, and items that are affected by the function's computer instructions. A function item (item) represents a position in a memory (for example, the memory 104) accessible by the function. An item has a type and a value. The types of items supported in one embodiment of the present invention include integer, floating point, and pointer data. An item value is a value represented by specific data stored at a location in the memory represented by the item. Externals and resources can be associated with each item of the function. Items will be described in more detail later. A variable associates between an identifier and one or more items.

  A function external represents a portion of a computer program that exists outside the context of the function, that is, before execution of the function begins or after execution of the function ends. Examples of function externals include function parameters and return value items, global definition variables, and static variables. The terms (i) “globally defined variable” and (ii) “static variable” are used herein to refer to (i) a variable whose linkage is “external” and (ii) whose linkage is “internal”, respectively. (Intern) "is used to represent a variable whose storage period is" static ". “Locally defined variable” is a variable whose linkage is “internal” and whose storage period is “automatic”. Linkage is described in C standard section 6.1.2.2, and storage duration is described in C standard section 6.1.2.4. In short, globally defined variables are defined for all subprocesses of a computer process, and static variables are defined for several subprocesses, but defined for all subprocesses of a computer process. Is not limited.

  Each partial process uses several resources. For example, function 202 (FIG. 2) of process 110 (FIG. 1) uses dynamically allocated memory 114 and computer process 116. The function 202 (FIG. 2) includes (i) a global definition memory 204 that can be accessed by the functions 202A and 202B and other functions, (ii) local memory, (iii) parameters 208A to 208C, and (iv) ) The return value item 210 is also used. The function 202 is analyzed by modeling one or more of these resources.

  Each resource and external has a state. The execution of each computer instruction of a function is emulated by modeling changes in the resource or external state of that function that would result from the actual execution of the computer instruction. When the state of the external or resource changes, the state change is compared with the corresponding external behavior model or resource behavior model, respectively, to determine whether the state change reflects the appropriate use of the external or resource. If the state change is inappropriate, a state violation occurs and an error is notified. Notification of the error to the user can be accomplished by (i) displaying the error message on the video monitor 118 (FIG. 1) or similar output device, and (ii) displaying the error message in the error log of the memory 104 or the secondary storage device 120. This can be done by recording to a file, or (iii) both displaying an error message and recording an error message.

The behavior model function model is an abstract representation of a new resource to which a function is assigned and an operation that the function performs on the external of the function.
As described above, a resource has a state. Valid states of resources and valid transitions between states are represented by a resource behavior model. Modeling the behavior of a resource can be greatly simplified over the actual behavior of that resource. For example, the state of the resource is modeled based on the resource behavior model represented by the state diagram 300 (FIG. 3A). Based on the state diagram 300, a resource can assume any of the following states.

  States U and X are similar but different. An item associated with an unassigned resource has an indefinite value, and an item associated with an invalid resource has a known invalid value. The resource behavior model can be as complex as the actual behavior of the resource being modeled. However, a greatly simplified resource behavior model, such as that represented in state diagram 300, is effective in detecting most of the total errors that can occur in the use of such resources.

Since the resource is not initially allocated, it is in state U. By emulated execution of each computer instruction (actual execution of them causes a state change of the resource), the operation is performed on the resource. By performing an operation on the resource, the state of the resource changes according to the state diagram 300.
The following are the operations that can be performed on resources.

As described above, according to the state diagram 300, when an unallocated resource, that is, a resource in the state U is appropriately allocated by an instruction in a certain function, that is, when an operation a is performed, the resource Is in state A, the assigned state. However, if an unassigned resource, ie a resource in state U, is used in the computation (and thus subjected to operation c), the resource is in state E. State E indicates that a state violation has occurred as a result of a programming error. State E is optional rather than representing a predetermined behavior of the resource, but in the disclosed embodiment, it is used as a convenient way to represent a state violation. In another embodiment, state E is omitted and a state violation is detected by noting that operation c is not defined when the resource is in state U in the above example.
State diagram 300 (FIG. 3A) is summarized as Table C.

  The superscript number corresponding to the operation identifier in the state diagram 300 and the superscript number added to the new status identifier in Table C indicate a specific error. These errors are as shown in Table D below.

In the above example, by applying operation c to a resource in state U, the resource is shown in the state diagram 300 as indicated by the arrow identified by “c ² ” going from state U to state E. Is placed in state E. Thus, the error in this example is error number 2 shown in Table D, ie the use of unallocated resources.

  Each function model defines which operations are performed on each external of the corresponding function. For example, the function fopen () defined for the C language described in section 7.9.5.3 of the C standard defines two parameters, of which the first parameter is taken as input and opened Identify the file that should be. Further, a return value item which is a file pointer corresponding to the opened file is defined. File pointers, ie pointers that specify items of type “FILE”, are well known and described in section 7.9.1 of the C standard. The file pointer is an external of the function fopen (), and the file specified by this parameter is a resource associated with this external. The function model for the function fopen () defines that a new resource is generated whose initial state is state Q. The initial state of this resource is state Q, not state A, because the function fopen () does not guarantee that the file is opened successfully.

  The function fclose () defined for the C language described in section 7.9.5.1 of the C standard defines a parameter that is a file pointer.

  By executing the function fclose (), a file having a file descriptor specified by the parameter is closed. The function model for the function fclose () determines that the operation k is applied to its parameters to reflect that the associated file is closed and thus opened. Similarly, a function model for a C language function that defines read and write operations on a file specifies that operation c is performed on the resource representing that file so that the file is used. .

  When an item corresponding to a certain resource (for example, a file pointer that is a return value item of the function fopen ()) is used as a predicate in a decision instruction, an operation p is applied to the resource. The state of the resource is changed based on the state diagram 300. The item is a relational expression (for example, an operation including any of the operators>, <, <=,> =, and! =) Or a Boolean expression (for example, an operation including any of the operators &&, ||, and!). An item will be used in a predicate if it appears as an operand in or if the item is used as a control expression in a "switch" statement. The “switch” statement is defined for the C language, and controls the function flow according to the value of the control expression. The “switch” statement is described in detail in section 6.6.4.2 of the C standard.

  When an item corresponding to a resource is used in the calculation, operation c is applied to the resource, thereby changing the state of the resource based on state diagram 300. An item is used in a calculation when (i) it appears as an operand to a mathematical operation (eg, +, /, *, or-), or (ii) a resource goes to a pointer dereference or array Or (iii) when a resource appears as an array index.

  Although pointers and arrays are well known and described in the C standard, pointers and arrays are briefly described below just in case. In the C language context, a pointer is an item whose value is the address in memory of another item. Thus, the pointer “points” other items. Dereferencing the pointer means searching for an item specified by the pointer.

  The data structures described in more detail below that are used to implement embodiments of the disclosed invention are described as including pointers that specify other data structures. Although mechanisms other than pointers for uniquely identifying data structures are known, it should be understood that these mechanisms can be substituted for pointers without departing from the principles of the present invention.

  An array is a collection of one or more items of similar structure. The items in the array are called elements and are numbered sequentially. An access to an array is an access to an element of the array by referring to the element number, that is, the index of the element.

  The operation x is performed on the resource corresponding to the item that is assumed to be NULL. NULL is generally an invalid value and is assigned to an item to indicate that the item does not have a valid value. For example, a pointer whose value is NULL does not specify an item. In the context of the C language, NULL is also a Boolean value representing “false”. If an item is compared to NULL and the result of the comparison is true, the item is NULL, i.e., has a value of NULL. As will be explained in more detail later, analyzing a function requires setting various assumptions about the specific behavior of the function at runtime. For example, the function fopen () either successfully opens the file or fails to open the file. If the return value item, i.e., the file pointer is compared to NULL and the result is true, i.e. if the function fopen () fails to open the file, the resource x represents the operation x. Applied. This will be described in more detail later.

Example for explaining the basic principle of the present invention The usefulness of resource modeling is explained below using an example. The following source code excerpt (1) contains a programming error, which is detected in the disclosed embodiment of the invention. This source code excerpt (1) conforms to the well-known C language, and the function example 1 () is defined. Line numbers are not part of the C language, but are added to make the following explanation easier to understand.

Function example When analyzing 1 (), the status of each item, including the external, is tracked. The variable “str” is defined locally, ie the function example 1 Defined only in the context of (). The variable “str” is a pointer that specifies data whose type is “char” as defined in the line 10. Initially, however, the variable “str” is not initialized and does not specify specific data. Therefore, the variable “str” is not associated with the resource.

  Execution of the function malloc () defined for the C language described in section 7.10.3.3.3 of the C standard accepts a request for the allocated memory (eg memory 104 (FIG. 1)) Allocate or fail to allocate memory. The function malloc () returns, as a return value item, a pointer designating the allocated memory if the memory allocation is successful, and a NULL pointer otherwise. In this way, the function malloc () generates a new resource whose initial state is Q, and associates the new resource with the return value item of the function malloc (). After the value of the return value item of the function malloc () is assigned in line 23, the variable “str” designates the newly allocated memory if the memory is allocated, and if not, with the NULL pointer. is there.

  In line 25 of the source code excerpt (1), the variable “str” is used as a parameter in the function fgets (). This function fgets () is also a function defined for the C language described in section 7.9.7.2 of the C standard. When the function fgets () is executed, the first parameter, ie, the variable “str” is dereferenced in the context of the line 25 of the source code excerpt (1). Therefore, the operation i is performed on the resource associated with the variable “str”. As shown in state diagram 300 (FIG. 3A) and Tables C and D, when an operation i is applied to a resource in state Q, the resource is placed in state A, and there is uncertain data whether it is allocated or not. An error message is generated indicating that it was used without being checked.

  In the line 29 of the source code excerpt (1), the variable “str” is passed as a parameter to the function free () that frees the memory designated by the variable “str”. Accordingly, the operation k is performed on the resource associated with the function “str”. As shown in state diagram 300 and Tables C and D, when operation k is applied to a resource in state A, the resource is placed in state U. Since it is appropriate to release the allocated resources, no error is reported.

The following text (2) is the function example of the source code excerpt (1). 1 illustrates an error message generated by an embodiment of the disclosed invention that parses ().

In the text (2), “example” 1. c ″ contains the source code excerpt (1) above, so the function example 1 Indicates a file that defines (). Function example 1 () takes into account that in the call to the function malloc () in line 23 of the source code excerpt (1) (ie execution request), there may be insufficient memory for the amount of memory required to be allocated. Not. Function example If the function malloc () fails to allocate the requested memory when 1 () is executed, the function example The computer process containing the execution of 1 () will abort abruptly and the user will not be given a reason for the unexpected termination of the process. However, for example, by using the text (2) above to detect and notify that such a situation is not taken into account, the function example 1 The function example is given to the developer of (). 1) The information necessary to correct the defects in () is given, and it becomes possible to appropriately deal with such a situation.

The utility of the present invention is that the function example of the source code excerpt (1) is used. It becomes more apparent by examining the tracking of the state of the file pointer “fptr” in 1 (). The file pointer “fptr” is a function example. 1 () Locally defined variable. The file pointer “fptr” is a pointer that designates data of the type “FILE”. Initially, the file pointer “fptr” has not been initialized and is not associated with any resource.

  In line 14, the return value item of the function fopen () is assigned to the file pointer “fptr”. As described above, the function fopen () generates a new resource in the initial state Q, and associates the return value item of the function fopen () with the new resource. The “if” statement in line 15 determines whether the file specified by the file pointer “fptr” has been opened normally by comparing the file pointer “fptr” with “NULL”.

If the file pointer “fptr” is NULL, the file has not been opened normally and the function example 1 () notifies the user that the file could not be opened normally and ends. Conversely, when the file pointer “fptr” is not NULL, it can be seen that the file specified by the file pointer “fptr” has been opened normally, and the function example 1 () goes to line 22. By comparing the file pointer “fptr” on line 15, the operation p is performed on the resource associated with the file pointer “fptr”. Accordingly, the state of the resource associated with the file pointer “fptr” changes from the state Q to the state A. Therefore, as shown in the state diagram 300 and Table C, no error message is generated when the file pointer “fptr” is used in either a calculation (application of operation c) or a predicate (application of operation p). . Accordingly, no error is detected regarding the processing of the file pointer “fptr”.

  As described above, the functions fopen () and malloc () execute specific processing on the parameters and the resource of the return value item at the time of execution. Functions such as functions fopen () and malloc () are included in library functions 112 (FIG. 1) accessible by computer process 110. Such function calls are included in function 202 (FIG. 2). In this specification, a “call” for a function is a statement that causes a processor such as the CPU 102 (FIG. 1) to perform the following processing at the time of execution. That is, (i) 0 or 1 or more items are given as parameters to the function, (ii) the function is executed, and (iii) a return value item representing a value generated by evaluation of the function (when the return value item is determined by the function) ) Is generated. If the first function includes a call to the second function, the first function is called a “calling function”. The second function is called a “called function”.

  In order to properly analyze the resource of function 202 (FIG. 2) affected by the execution of the function called by the statement of function 202, a function model describing the behavior of such a called function is supported. In one embodiment, such a function model is generated from a known textual description that defines the behavior of such a function, for example in the C standard, and is stored in the memory 104 of the computer 100. These function models are then retrieved and retrieved from memory 104 prior to analysis of the computer program. This will be described in more detail below.

The function example of the above source code excerpt (1) is shown below. 1 An example of a function model of a function called by () is shown. These called functions are all from the “stdio” (input / output) header file of the C standard library. This header file is a well-known file used in the C language, and is shown in section 7.9 and below of the C standard.

  The function model structure representing the function model in the memory 104 (FIG. 1) according to the disclosed embodiment of the present invention will be described in detail later. The function model (3) defines the effect that the execution of the function malloc () has on the external state of the function malloc (). According to the function model (3), a new resource is generated, initialized to the state Q, and associated with the return value item of the function malloc (). The function model (3) also defines that the operation C is performed on the first parameter of the function malloc (), that is, the parameter 0 (parameter O).

The function model (4) defines the effect of execution of the function free () on the external of the function free (), and the operation k is applied to the first parameter of the argument list, that is, the parameter 0. Is shown.

  In the function model (5), by calling the function fgeps (), (i) the operation i is applied to the parameter 0, that is, the first parameter, (ii) the operation c is applied to the parameter 1, that is, the second parameter, (Iii) The calculation i is performed on the parameter 2, that is, the third parameter.

Resource Leak Detection By modeling resources and tracking the relationship between resources and function externals, the disclosed error detection mechanism provides a useful mechanism for detecting resource leaks. A resource is "leaked" by a function when it exits with the resource assigned to it, that is, when the resource becomes inaccessible by any external of the function. When leaked, the resource cannot be used because the pointer specifying the resource is not held after the execution of the function causing the leak is completed. If a resource is reusable, such as dynamically allocated memory 114 (FIG. 1), other functions reuse the resource if the resource is not freed before the end of function execution You can't. If a partial process repeatedly leaks dynamically allocated memory, it can eventually result in exhaustion of all available memory for the computer process that contains the partial process.
As an example of resource leak detection, the function example in the source code excerpt (6) 2 Think about ().

The variable “str” is a function example. 2 () is a local variable, so the function example 2 Functions other than () are not accessible. Since the memory designated by the variable “str” is not freed before the “return” instruction in the line 25 of the source code excerpt (6), this memory has the function “example”. It cannot be used until the computer process 110 that includes 2 () as its part is terminated, and cannot be released or reassigned. Therefore, this resource “leaks” from the computer process 110.

  Since the function external is an item that exists even after the execution of the function ends, the allocated resources that are reachable through the external are not leaked. Resources that are not associated with a particular external are also reachable through the external in some cases. For example, a resource associated with a particular element of an array of items is reachable through an external that is another element of the array of items. This is because according to the C language, the position in memory of an element of an array can be calculated from the position of another element of the array.

Leaks are checked at the end of the function traversal. Since leak detection will be described in more detail later, it will be briefly summarized here. Mark all resources reachable through the external. Resources that are not marked and allocated are reported as leaked. Since the variable “str” is not returned in line 25, the variable “str” is not external. Thus, the memory specified by the variable “str” is allocated and the function example 2 Not marked at the end of () traverse. Therefore, the memory indicated by the variable “str” is leaked.
Function example 2 The analysis of () generates the following error message:

  Prior art static checkers cannot detect resource leaks. Prior art runtime checkers often do not consider all possible events that can cause a resource to leak into a function, generally analyzing a single function outside the context of a large computer program It is not possible to detect resource leaks within a single function. In contrast, in the disclosed embodiment of the present invention, resource leaks are effectively detected by analyzing a single function of a large computer program. As described in more detail below, the disclosed error detection mechanism considers all possible events that cause the function to cause a resource leak. Thus, the present invention is a significant improvement over the prior art.

External Compound State As described in detail below, the analysis of a function follows the flow of control of that function, emulates the execution of individual statements of that function, and tracks the state of externals and resources. Made. The flow of control of a function is a specific order of the computer instructions for that function that are executed during the specific execution of that function. When control is transferred from the first computer instruction to the second computer instruction, the second computer instruction is executed following execution of the first computer instruction. A function control flow is often referred to herein as a function control flow path. The flow of function control often depends on the particular event that occurs during the execution of the partial process defined by the function in the computer process.

  In function analysis, it is desirable to consider all possible control flow paths of the function. Therefore, it is desirable to consider all events that can affect the control flow path of the function. Prior art static checkers often do not consider the control flow path at all. The run-time checker operates on events that affect the control flow path of a function to the extent that the user can force the computer process to follow each control flow path during execution of the computer process. It only considers the control flow path of the function. On the other hand, the disclosed error detection mechanism automatically analyzes each control flow path of the function without user intervention. Further, the disclosed error detection mechanism can perform the analysis of a function outside the context of a computer process or computer program that includes the function. Thus, individual functions can be more thoroughly checked for errors before being incorporated into a larger function or computer program or process.

As an example, the function example in the source code excerpt (6) 2 Think about (). Function example 2 The exact control flow path of () is the function example 2 It is unknown until () is executed in a computer process. For example, if the function malloc () called on line 14 succeeds in allocating memory as requested, control passes from the "if" statement on line 16 to the call to the function fopen () on line 19. Flowing. In other words, if the function malloc (), when called on line 14, successfully allocates memory as requested, the call of the function fopen () on line 19 follows the execution of the "if" statement on line 16. . Conversely, if memory allocation fails, control flows from the “if” statement on line 16 to the “return” statement on line 17. Whether it is normally allocated by the function malloc () when called in line 14 is usually determined by the function example in the computer process. 2 I don't know until () is executed.

Function example In the analysis of 2 (), it is desirable to consider all control flow paths of the function example2 (). By traversing the function over and over with different assumptions, multiple control flow paths are considered. For example, the function example 2 () is the assumption that once the function malloc () called on line 14 successfully allocates the requested memory, the function malloc () fails to allocate the requested memory once. Traversed.

In one embodiment of the present invention, which will be described in detail later, a traversal is performed repeatedly for one function, and an assumption is set at random in each traverse. Function example 2 Each traverse of () is a function example 2 Track the external state of (). Each external uses the function example 2 (Composite state) reflecting several states of each external obtained as a result of multiple traverses of ().

  External has composite RS, CP and DK states. These composite states are used for two purposes. That is, (i) in order to detect the use of an external that causes inconsistencies when considering various control flow paths of the function, (ii) construct a function model that describes the effect of function execution on the external of the function. Therefore, it is used for. The constructed function model can then be used to analyze other functions that call the modeled function.

  Within the context of a particular function, each external has a CP state, a DK state, and an RS state. The ecternal CP state is used to determine if the external is checked before being used. The term “CP” mainly comes from the operation of interest, ie the operation c (representing the use of external) before the operation p (representing an external check). The external DK state is used to determine whether the function assigns and / or releases ecternals. The term “DK” is used for the purpose of the DK state, ie, to determine whether a resource is killed (“K”), ie, defined (“D”) before being released. Yes. The RS state of the escalator is the state of the associated resource when the resource is associated with the external. The term “RS” comes from the resource (“R”) state (“S”).

  Each external of a function has a composite CP state, a composite DK state, and a composite RS state that respectively reflect a plurality of CP, DK, and RS states resulting from multiple traversals of the function. After each traversal of the function to be repeated, an external new composite RS state is sought, as will be described in more detail below, the external new composite RS state is defined as: And the RS state of the resource associated with the external resulting from the most recent traversal of the function. Similarly, as described in more detail below, the new composite CP and DK states are determined from the previous composite CP and DK states and the CP and DK states that result from the most recent traversal of the function, respectively.

  State diagram 350 (FIG. 3B) represents the states and state transitions for the composite RS state. The arrows in state diagram 350 represent a composite RS state transition from the previous composite RS state based on the RS state resulting from the function traversal. State diagram 350 is summarized as Table E.

  A state diagram 400 (FIG. 4A) represents states and state transitions for the CP state of the estuary. In the state diagram 400, an arrow represents a CP state transition that occurs as a result of the operation. The external may have the following CP or composite CP state.

  The operations that can be performed on the escutial are as described above with reference to Table B. The state diagram 400 is summarized in Table H below.

  State diagram 450 (FIG. 4B) shows the states and state transitions for the external composite CP state. The arrows used in state diagram 450 represent the transition of the composite CP state from the previous composite CP state based on the CP state resulting from the function traversal. The state diagram 450 is summarized in Table I below.

  A state diagram 500 (FIG. 5A) shows states and state transitions with respect to the DK state of Escarnal. In the state diagram 500, the arrows are used to represent DK state transitions resulting from the operation. An escutral may have the following DK or composite DK state that reflects the effect that function execution has on the resources associated with the escalator.

  The operations that can be performed externally are as described above with reference to Table B. The state diagram 500 is summarized in Table K below.

  State diagram 550 (FIG. 5B) represents the states and state transitions for the external composite DK state. Arrows in state diagram 550 are used to represent composite DK state transitions from previous composite DK states based on DK states resulting from function traversal. State diagram 550 is summarized in Table L below.

Function example in the above source code excerpt (6) 2 () is an example showing the usefulness of the external composite state.

As described above, the function example The control flow of 2 () passes through one of a plurality of paths depending on assumptions set in relation to events at the time of execution of functions by emulation. For example, if the variable “str” is not NULL, the “if” statement on line 16 is followed by the “return” statement on line 17; otherwise, the expression on line 19 follows. Function example 2 The return value item of () is the function example. 2 () is an external. Function example 2 The assignment to the return value item of () is the function example 2. Based on specific assumptions set in a specific traverse of (2), made at line 17, line 25 or line 29 of source code excerpt (6).

In line 17 or line 25, no resource is associated with the return value item. Therefore, a function example in which control flows through either line 17 or line 25 of the source code excerpt (6). After the traverse of 2 (), the complex RS state of the escaper representing the return value item becomes the state U. Subsequently, when the function example-2 () is traversed so that the control passes through the line 29, the external representing the return value item becomes the function example. 2 Associated with the resources created in () and allocated appropriately. That is, state A is entered. Lines 16 to 17 in the source code excerpt (6) adequately describe the action to be taken for the event that memory is not properly allocated by execution of the function malloc (), so that the resource An assignment is made.

As shown in state diagram 350 (FIG. 3B), an external whose previous composite RS state is state U and the next RS state is state A has a new composite RS state of state Q. This is the function example The execution of 2 reflects that the memory specified by the return value item can be allocated, but is not necessarily allocated. Therefore, the function example When the function model describing the behavior of 2 is formed, the function example The return value item of 2 is described as being associated with a newly generated resource whose initial state is state Q.

  In addition, using the composite state, it is possible to detect the inconsistent use of the external by the function. For example, a function terminates in an assigned external state, ie, an RS state in state A, and in a subsequent traverse of the function, the function releases the same external, ie, an RS state in state K. When the process ends, the complex RS state of the escalator becomes state E. This can be considered an error. This is because, in general, it is required to allocate resources associated with one external in the execution when there is a calling function, and to release resources associated with the same external in other cases. It is because it cannot be considered.

Computer Program Analysis The analysis of the computer program 610 (FIG. 6) is based on the present invention, as described herein, a resource checker that analyzes the use of resources defined by the computer program 610. 602. In the disclosed embodiment, the resource checker 602 is a computer process that is read from the memory 104 connected to the CPU 102 via the bus 108 and executed on the CPU 102.

  The analysis of computer program 610 according to the present invention is shown in logic flow diagram 900 (FIG. 9). The process begins at step 902. For example, an environmental characteristic in which the computer program 610 is analyzed is specified by a command input by the user using the keyboard 124 (FIG. 1) or the mouse 122, and analysis of the computer program 610 (FIG. 6) is started. User-modifiable environmental characteristics include (i) the type of error to be detected, (ii) the maximum number of errors to be notified, (iii) the maximum number of functions to be analyzed, and (iv) the traversal of each function. There are a maximum number of iterations, and (v) a specific method for traversing all possible control flow paths of the function.

  The process proceeds from step 902 (FIG. 9) to step 904, where the resource checker 602 (FIG. 6) initializes a function model that describes the effect of the execution of various functions used by the computer program on the resource. Turn into. The resource checker 602 includes a model parser 702 (FIG. 7). The model parser 702 reads a model from the model description file 604 (FIG. 6), and constructs a function model structure described later from the read model. The function model is initialized by generating a function model structure in the resource checker 602.

  Step 904 (FIG. 9) will be described in more detail later with reference to logic flow diagram 904 (FIG. 10).

  The process proceeds from step 904 (FIG. 9) to step 906, where the program parser 704 (FIG. 7), which is part of the resource checker 602, reads the computer program 610 (FIG. 6) and reads the prior art. And parsing based on the language that the computer program 610 follows. Program parser 704 (FIG. 7) parses computer program 610 (FIG. 6) and breaks it down into smaller program components, eg, functions. In step 906 (FIG. 9), one function is extracted from the computer program 610 (FIG. 6) by parsing, and the function structure representing the extracted function is the dynamic inspection engine (dynamic inspection) described in detail later. engine) 706. In another embodiment, a preprocessor described later parses the computer program 610, and a plurality of function structures representing a plurality of functions in the computer program 610 extracted by parsing are stored. In this alternative embodiment, program parser 704 serves to retrieve one function structure and send the retrieved function structure to dynamic inspection engine 706. The process proceeds from step 906 (FIG. 9) to step 908.

  In step 908, the dynamic inspection engine 706 (FIG. 7), which is part of the resource checker 602, causes a “subject function”, ie, the dynamic inspection engine 706 by the program parser 704 in step 906 (FIG. 9). The function represented by the function structure sent to is analyzed. In other words, the effect generated in the resource used by the computer program 610 as a result of the execution of the subject function is obtained, and the state transition of each resource affected by the execution of the subject function is analyzed. This will be described in more detail later. The function model initialized in step 904 is used to analyze subject function externals, resource states and state transitions. The detected state violation is notified as a programming error.

  When the behavior of the subject function is defined with respect to its externals and resources, the model parser 702 forms and stores a function model that describes the behavior of the subject function in the model description file 604. Step 908 (FIG. 9) will be described in more detail later with reference to logic flow diagram 908 (FIG. 24).

The process proceeds from step 908 (FIG. 9) to test step 910, where program parser 704 (FIG. 7) further parses computer program 610 (FIG. 6) to computer program 610, step 908 (FIG. 9). 9) based on whether the function to be analyzed by the dynamic inspection engine 706 (FIG. 7) is still included. In another embodiment as described above, the program parser 704 (FIG. 6) provides functions of the computer program 610 that must be analyzed by the dynamic inspection engine 706 (FIG. 7) based on step 908 (FIG. 9). Determine if there is still a function structure to represent. If there is a function structure representing a function of the computer program 610 that has not yet been processed by the dynamic inspection engine 706 (FIG. 7), the process proceeds to step 906 (FIG. 9), where the program parser 704 (FIG. 6). ) Sends the functional structure to the dynamic inspection engine 706 (FIG. 7) as described above. If the dynamic inspection engine 706 (FIG. 7) has processed all the function structures representing the functions of the computer program 610, the process ends according to the logic flow diagram 900 (FIG. 9).

Model Initialization As described above with reference to step 904 (FIG. 9) of logic flow diagram 900, the function model describing the behavior of the function is initialized. Step 904 is shown in detail in logic flow diagram 904 (FIG. 10). The process begins at step 1002, where a model description file 604 (FIG. 6) is opened that includes a functional model as described above.

  In one embodiment, the function model is stored in text form, read and stored in a data structure detailed later in memory 104 (FIG. 1). The function model includes information identifying the function and a single-linked list of external models relative to the external of the function. Information identifying the function includes (i) the function name, (ii) the name of the source code file in which the function is defined, (iii) the number of the text line in the source code file where the function definition begins, and (iv) Contains a brief description of the function. The source code file is a file for storing a computer program such as the computer program 610 stored in the memory 104 (FIG. 1) (usually a secondary storage device such as a magnetic disk). External models stored in the form of a single linked list define the effect of function execution on function externals with respect to the operations performed on these externals and the resources generated in relation to those externals. Is.

  The external model includes information that identifies the type of external, information that identifies the external, and information that defines the effect of function execution on the external. The information for identifying the external is a parameter number when the external is a parameter, a variable name when the external is a global or static variable, and NULL when the external is a return value item. Information defining the effect of function execution on the external includes (i) a list of operations performed on the external, (ii) a flag indicating whether a new resource is generated in relation to the external, and (iii) When a new resource is created, the initial state of the new resource is included.

  The text format of the model stored in the model description file 604 (FIG. 6) conforms to the following “Backus-Nour Form (BNF)” definition (8). “Backus-Nour Form” is a well-known format for describing formal languages.

  In the text format, the function model is represented by a non-terminal <function-spec> of the BNF definition (8). In BNF, a terminal is an item that is not further expanded in a specific BNF definition, while a non-terminal is an item that is further expanded. The terminal <function-name> is an identifier to be used when another function calls a function to be identified, that is, a function represented by a function model. The terminal <function-name> may be any function identifier that is valid in the computer language used to define the function. The terminal <defining-file> identifies the source code file in which the function is defined with alphanumeric characters. As such alphanumeric identification, for example, the path of the source code file may be described. The terminal <defining-line> is a definition of a function that is modeled in any text line of the source code file identified by the terminal <defining-file> by means of a text representation using non-negative digits, i.e. digits 0-9. It is to specify whether or not.

  In BNF, an option item is represented by being enclosed in square brackets (“[]”). Accordingly, the terminals <function-prefix>, terminals <defining-file>, <defining-line>, and <description> are optional. A series of slash symbols (“//”) indicates the start of a comment sentence, and these slashes and the text sentence that continues to the end of the text line after these slashes are part of the BNF definition. Note that is not considered.

  The terminal <description> in the BNF definition (8) is a sequence of one or more characters (ie, letters, numbers, and / or symbols). The terminal <description> is not used by the resource checker 602 (FIG. 6), but is provided for the convenience and understanding of the user who reads the model expressed in the text format. The terminal <param-number> in the BNF definition (8) is a text expression of a non-negative integer using numbers from 0 to 9, and designates a specific parameter in the parameter list. Parameter zero is the first or leftmost parameter in the parameter list in the function call. Subsequent parameters are numbered sequentially. The terminal <var-name> in the BNF definition (8) is a variable identifier.

  Each function model extracted from the model description file 604 (FIG. 6) describes the effect of execution of each function on the external of the function. The process proceeds from step 1002 (FIG. 10) to loop step 1004, and each function model stored in model description file 604 (FIG. 6) is defined by loop step 1004 (FIG. 10) and NEXT step 1004. Are taken out and processed according to the loop In each iteration of the loop, the function model being processed is referred to as the current function model. When the processing of all function models stored in the model description file is completed according to the loop defined by the loop step 1004 and the NEXT step 1014, the process proceeds from the loop step 1004 to the step 1006, and the model description file 604 (6th Is closed and the process based on logic flow diagram 904 (FIG. 10) ends.

  For each function model retrieved from the model description file, the process proceeds from loop step 1004 to step 1008 where a portion of the current function model corresponding to the non-terminal <function-prefix> of BNF definition (8) described above is Separated from the current function model. The process proceeds to step 1010 where the function model structure is initialized and information separated from the current function model in step 1008 is stored in the function model structure.

  The function model structure 1100 (FIG. 11) includes a field “name” 1102, a field “file” 1110, a field “line” 1112, and a field “description” 1108. Function model corresponding to terminals <function-name>, <defining-file>, <defining-line>, and <description> of BNF definition (8) (all of which are part of non-terminal <function-prefix>) Are extracted from the function model and stored in a field “name” 1102, a field “file” 1110, a field “line” 1112, and a field “description” 1108 of the function model structure 1100. The process proceeds from step 1010 (FIG. 10) to loop step 1012.

  The loop is defined by the loop step 1012 and the NEXT step 1028, and in each iteration, the external processing shown in the function model corresponding to the non-terminal <external-list> of the above-described BNF definition (8) Is made. The external being processed in each iteration of the loop defined by loop step 1012 and NEXT step 1028 is called a subject external. When the processing of all externals defined in the current function model ends according to the loop defined by loop step 1012 and NEXT step 1028, the process proceeds from loop step 1012 to NEXT step 1014. The process proceeds from NEXT step 1014 to loop step 1004, where another function model retrieved from model description file 604 (FIG. 6) is further processed, or if all function models have been processed, As described above, the process proceeds to step 1006 (FIG. 10).

  For each external indicated in the part of the current function model corresponding to the non-terminal <extern-Iist> of the BNF definition (8), the process proceeds from loop step 1012 to step 1016. In step 1016, a new external model structure, such as external model structure 1200 (FIG. 12), is generated.

The external model structure 1200 includes a field “equivalent” 1202, a field “type” 1204, and a field “parameter”. number "1206, field" name "1208, field" next "1210, field" number " of "operations" 1212, field "operations" 1214, field "new" resource "1218, field" initial " state “1220” and a field “description” 1222. In step 1016 (FIG. 10), the subject external corresponding to the terminal <param-number> in the definition of the nonterminal <external> of the BNF definition (8). The part of the model is taken from the subject external model and the field “parameter” of the external model structure 1200 number "1206 (FIG. 12).

  In one embodiment, the field “equivalent” 1202 is used to identify a second external model structure. By doing so, the external model structure 1200 is related to the second external model structure. For example, if the return value item of the function is the first parameter, it would be appropriate to do so. In the embodiment disclosed herein, the field “equivalent” 1202 is not used, so this field is initialized to a NULL value. From step 1016 (FIG. 10), the process proceeds to step 1018.

  In step 1018, the portion of the subject external model corresponding to the non-terminal <external-type> of the BNF definition (8) that defines the type of external represented by the subject external model is extracted from the subject external model. As shown in BNF definition (8) above, the external represented by the external model can be a return value item, a parameter, or a global definition / static variable.

  Data indicating the type of the external represented by the subject external model is stored in the field “type” 1204 (FIG. 12) of the external model structure 1200. The process proceeds from step 1018 (FIG. 10) to loop step 1020.

  As shown in the BNF definition (8) above, execution of a function may have one or more effects or “results” on each external of the function. Each result is represented as non-terminal <result> in the BNF definition (8). One or more results are included in the non-terminal <result-list>. In the loop defined by the loop step 1020 and the NEXT step 1024, each result in the non-terminal <result-list> list of the subject external model is processed. The result being processed in the repetition of the loop defined by the loop step 1020 and the NEXT step 1024 is referred to as a processing result (subject result). As described below, once all results of the subject external model are processed based on the loop defined by loop step 1020 and NEXT step 1024, the process proceeds from loop step 1020 to step 1026.

  For each result for the subject external model, the process proceeds from loop step 1020 to step 1022. In step 1022, the processing target result is extracted from the subject external model. This result is stored in an external model structure such as an external model structure 1200 (FIG. 12). For example, the function model (3) defined above defines one result for the first external, that is, the return value item, and one result for the second external, that is, the parameter 0. The result of the return value item is defined as “(new Q“ memory ”)”, indicating that a new resource is generated for the return value item, and that the initial state of the resource is state Q. Furthermore, “memory” is given as a brief description of the resource.

Accordingly, when the external model structure 1200 represents the external model for this return value item, (i) the field “new” “resource” 1218 is set to a Boolean value of “true” to indicate that a new resource is to be created, and (ii) the field “initial” indicates that the initial state of the new resource is state Q. “state” 1220 is set, and (iii) the text “memory” is stored in the field “description” 1222.

As a second example, the function model (3) defines a result “(op c)” for the second external, ie, parameter 0. The result “(op c)” indicates that the operation C is performed on the external. Therefore, if the external model structure 1200 represents an external model for the parameter 0, the field “number” having 0 as an initial value. of The operations “1212” is incremented (incremented by 1), and the operation identifier “c” is set in the field “number”. of Stored in the field “operations” 1214 corresponding to the position indicated by the operations “1212. In this example, the field“ number ” of The operations “1212” stores the value 1, and the first operation identifier in the field “operations” 1214 is the identifier of the operation c. If the second operation is applied to the second external, the field “number” of The operations “1212” is incremented once again to become the value 2, and the second operation identifier in the field “operations” 1214 becomes the identifier of the second operation.

  The process returns from step 1022 (FIG. 10) via NEXT step 1024 to the loop step 1020 described above. As described above, the process proceeds from loop step 1020 to step 1026 when all results for the subject external model have been processed.

In step 1026, the external model structure representing the subject external model is added to the external single linked list in the current function model structure. It will be described in the context of the above function model (3). First, the field “first” of the function model structure 1100A. "external" 1004A and "last" The external model structure 1200A (FIG. 13) is added to the function model structure 1100A by storing a pointer that designates the external model structure 1200A in the external “1106A. Subsequently, the field“ “next” 1210A and the field “last” of the function model structure 1100A In “external” 1106A, a pointer pointing to the external model structure 1200B is stored as shown in FIG. 13 (field “last”). By replacing the pointer previously stored in external "1106A), the second external model structure 1200B is added to the function model structure 1100A.

  The process proceeds from step 1026 (FIG. 10) through NEXT step 1028 to loop step 1012. As described above, when all external models have been processed, the process proceeds from loop step 1012 to loop step 1004 via NEXT step 1014. As described above, when all the function models have been processed, the process proceeds from loop step 1004 to step 1006, and the file including the function model described in the text format is closed as described above. The process based on logic flow diagram 904 ends after step 1006.

When the computer program 610 (FIG. 6) is parsed by the function internal representation program parser 704 (FIG. 7), the computer program 610 is represented in the memory 104 by a series of function structures. In another embodiment described above, the program parser 704 serves to retrieve from the computer program 610 a functional structure formed by pre-parsing a source computer program that conforms to a particular computer language, such as C language. The source computer program is parsed by a source code preprocessor, which parses the source computer program based on the computer language that the source computer program follows and is defined in the source computer program in the computer program 610 A function structure representing a function is formed and stored. This source code preprocessor (not shown) is a computer process separate from the resource checker 602.

  In this alternative embodiment, the source code preprocessor is based on the “GNU C Compiler” available from “Free Software Foundation, Inc” of Cambridge, Massachusetts. The list of computer instructions that are part of this specification and shown in Appendix B, which is hereby incorporated by reference in its entirety, shows the extracted computer program functions from the source code processor. It defines a data structure and a function for moving to a data structure described in detail later for representation. In one embodiment, a conventional compiler, such as the known “GNU C Compiler” described above, is used to parse the computer program, and the parsed program is stored in a data structure as defined in Appendix B. expressed.

  The function structure will be described below. A better understanding of the fields and relationships within the function structure will make it easier to explain the processing of the dynamic inspection engine 706 (FIG. 7) below.

The function structure 1400 (FIG. 14) represents a function defined by a computer program 610 or, in another embodiment, as described above, a source code program, and (i) a field “name” 1402, ( ii) field “line” 1404; (iii) field “file” 1406; (iv) field “result” 1408; (v) field “externals” 1410; and (vi) field “statement”. The field “name” 1402 of the function structure 1400 specifies the identification of the function represented by the function structure 1400. For example, the function example in the above source code excerpt (1) 1 The identifier of () is “example” 1 ".

A field “file” 1406 and a field “line” 1404 indicate a source code file in which a function represented by the function structure 1400 is defined, and a line number in the file, respectively. For example, the above source code excerpt (1) is the file name “example”. 1. If the entire contents of the source code file of c ″ are assumed, the function example The field “file” 1406 and the field “line” 1404 of the function structure representing 1 () are respectively the text “example”. 1. Stores c ″ and integer value 7 data.

A field “result” 1408 specifies a declaration structure 1418. This declaration structure 1418 is the same as the declaration structure 1506 described below, and defines the result type that the function represented by the function structure 1400 returns. For example, the function example in the above source code excerpt (1) 1 () returns an integer result, as shown in line 7 of source code excerpt (1). That is, data of type “int” is returned. Therefore, the function structure 1400 is converted into the function example In the case of 1 (), a field “result” 1408 specifies a declaration structure 1418 that defines integer data.

  A field “externals” 1410 of the function structure 1400 is a pointer that designates an external list structure 1414 to be described in more detail later. As will be described in detail later, an external list structure such as external list structure 1414 is a pointer used to link a plurality of external list structures to form a single-linked list. Is included. Therefore, including the case where the length of the list is 1, designating one external list structure is designating a single linked list of the external list structure. Such a single linked list specified by the field “externals” 1410 of the function structure 1400 includes an external list structure that represents the external of the function represented by the function structure 1400.

Field “first” of function structure 1400 stmt "1412 is a pointer that points to a statement structure 1416 that will be described in more detail later. As will be described in more detail later, a statement structure, such as statement structure 1416, allows multiple statement structures to be single-ended. Contains pointers used to link to form a linked list, so specifying a statement structure, including the case where the length of the list is 1, is a single link of the statement structure The field “first” of the function structure 1400. Such a single linked list specified by stmt "1412 includes a statement structure that represents a statement of the function represented by the function structure 1400.

External List Structure The external list structure 1414 is shown in detail in FIG. The external list structure 1414 represents the external of the function represented by the function structure 1400 (FIG. 14), and includes the field “first”. decl "1502 (Fig. 15), field" next "1504, and field" first " contains "external" 1510. Field "first" The decl “1502” is a pointer that specifies a declaration structure 1506 that defines the external data type represented by the external list structure 1414. The field “next” 1504 is an external field, as will be described in more detail later. In the single linked list, when the external list structure 1508 follows immediately after the external list structure 1414, it is a pointer that designates the external list structure 1508. In the single linked list of the external list structure, the external list structure 1414 has If there is no subsequent external list structure, the field “next” 1504 of the external list structure 1414 is NULL, that is, it includes NULL data. "First The external “1510” is a pointer that designates an external state structure (not shown) indicating the external state represented by the external list structure 1414, as will be described in more detail later.

The declaration structure declaration structure 1506 is shown in detail in FIG. A declaration structure is a variable or function that is declared, that is, a structure that defines a variable or function specified in the declaration. Declarations in the context of the C language are well known and are indicated in the C standard. The declaration structure 1506 includes a field “kind” 1602, a field “name” 1604, a field “type” 1606, a field “item” 1608, and a field “model” 1610.

  The field “kind” 1602 contains data indicating whether the item or function being declared is globally defined, static, or locally defined. The field “name” 1604 includes text data that identifies the identifier of the item or function. As mentioned above, in the C language context, an item or function is identified by a textual identifier, which must follow a predetermined format as described in section 6.1.2 of the C standard.

  A field “type” 1606 of the declaration structure 1506 is a pointer that points to a type structure 1612 that defines a particular type of data represented by the item or function being declared. The mold structure 1612 will be described later. A field “item” 1608 is a pointer that specifies an item structure 2700 that represents an item to be declared. When the declaration structure 1506 represents a function to be declared, the field “item” 1608 is NULL, so no item structure is specified.

  A field “model” 1610 of the declaration structure 1506 is a pointer that specifies the function model structure 1100 when the declaration structure 1506 represents a function declaration and the model of the function is represented by the function model structure 1100. . If the declaration structure 1506 does not represent a function declaration, the field “model” 1610 is NULL, that is, contains NULL data. Therefore, no function model structure is specified. Also, when the declaration structure 1506 represents the declaration of a function, but the function model structure of the function does not exist, the field “model” 1610 is NULL.

Mold Structure FIG. 17 shows the mold structure 1612 in detail. Type structures such as type structure 1612 define specific data types such as integers, floating point numbers, alphanumeric characters, and user-defined types such as structures. The type structure 1612 includes a field “kind” 702, a field “name” 1704, a field “size” 1706, and a field “points”. to "1708, and a field" fields "1710. The field" kind "1702 has a type represented by a type structure 1612 of an integer, a real number (ie, floating-point numeric data), a pointer, an array, and a structure. (That is, the data type “struct” defined for the C language), or data specifying whether it is a union, each of these types being known and section 6. 1.2.5 and 6.5 and later.

  The field “name” 1704 of the type structure 1612 includes alphanumeric data that identifies an identifier of the type if the type represented by the type structure 1612 is user-defined. If the type represented by the type structure 1612 is predetermined by the C language, the field “name” 1704 is NULL.

  The field “size” 1706 defines the size of the type represented by the type structure 1612. When the type is not an array, a field “size” 1706 indicates the number of bits of data included in the item of the type represented by the type structure 1612. For example, if the type is a 32-bit integer, the field “size” 1706 of the type structure 1612 indicates the value 32. If the type is an array, the field “size” 1706 is an element included in the entire array in the number of bits of data included in the entire array, ie, the number of bits of data included in the item of that type represented by the elements of the array. Represents the product of the number of. For example, assume that an array of 10 elements is declared by the declaration “int array [10];”. When the type “int” is a 32-bit integer, the size of the declared array is 10 elements × 32 bits. Therefore, the size of the array is 320 bits.

If the type represented by the structure 1612 is a pointer specifying another data type, the field “points” “to” 1708 is a type structure representing another data type, that is, a pointer that designates the type structure 1712. The type structure 1712 is similar to the type structure 1612. Conversely, the type structure 1712 is represented by the type structure 1612. If the type is not a pointer, the field “points” “to” 1708 becomes NULL.

  When the type represented by the type structure 1612 is a structure type (that is, a C language type “struct”) or a union type, a field “fields” 1710 is a field representing the first field of the structure type or the union type, respectively. It becomes a pointer that designates the structure 1714. As described in more detail below, field structures corresponding to a particular structure type or union type field are linked to form a single linked list. If the type represented by the type structure 1612 is neither a structure type nor a union type, the field “fields” 1710 of the type structure 1612 is NULL.

The field structure field structure 1714 is shown in detail in FIG. The field structure 1714 includes a field “name” 1802, a field “size” 1804, a field “offset” 1806, and a field “next” 1808. The field structure 1714 will be described in the context of the following type definition example based on the C language.

  The type definition in the source code excerpt (9) defines a structure type having an identifier “point” and having two fields. The type “point” is thus a structure type. Each field is of type “int”, which is typically a 32-bit integer. Each field has an identifier “x” or “y”.

  Field “name” 1802 of field structure 1714 includes alphanumeric data that identifies the identifier of the field represented by field structure 1714. For example, the field “name” of the field structure representing the first field of the structure defined in the source code excerpt (9) contains the text “x”.

  A field “size” 1804 of the field structure 1714 indicates the number of bits of data included in the field represented by the field structure 1714. For example, in a typical example of C language as compiled by “SunOS C compiler” sold by Sun Microsystems, Inc. of Mountain View, Calif., The type “ The item “int” is 32 bits long. In the source code excerpt (9) example, each field is a 32-bit integer and therefore contains 32-bit data. Accordingly, the field “size” of each field structure representing an individual field indicates an integer value 32.

  The field “offset” of the field structure 1714 represents an offset from the start of the structure to the data of the field represented by the field structure 1714. For example, since the field “x” in the source code excerpt (9) is the first field of the type “point”, the offset is 0.

  The type “point” is shown schematically in FIG. Field “x” of type “point” is 32 bits long and starts at offset 0. Field “y” of type “point” is 32 bits long and starts at offset 32. Therefore, the field “offset” 1806X (FIG. 20) of the field structure 1714X (which is exactly the same as the field structure 1714 (FIG. 18) and represents the field “x” of the type “point”). ) Indicates the integer value 0. Similarly, the field “offset” 1806Y (FIG. 20) of the field structure 1714Y representing the field “y” of the type “point”, which is exactly the same as the field structure 1714 (FIG. 18), indicates the integer value 32. .

A field “next” 1808 (FIG. 18) of the field structure 1714 is a pointer that designates the next field structure in the single linked list of field structures of a given structure type. For example, the field “fields” 1710P (FIG. 20) of the type structure 1612P representing the type “point” specifies the field structure 1710X representing the field “X” which is the first field of the type “point”. The next field of type “point” is field “Y”. Accordingly, the field “next” 1808X of the field structure 1714X specifies the field structure 1714Y representing the field “y” of the type “point”. The field “y” of the type “point” is the last field of the type “point”, and there is no other field of the type “point” thereafter.
Therefore, the field “next” 1810Y of the field structure 1714Y is NULL.

Statement Structure As described above, the field “first” of the function structure 1400 stmt "1412 (Figure 14) specifies a statement structure 1416. The statement structure 1416 is shown in detail in Figure 21. Statement structures such as the statement structure 1416 are based on the C language. Represents a plurality of statements that together form a function: statement 1416 includes the following fields: (i) field “kind” 2102, (ii) field “line” 2104, (iii) field “next” 2106, (Iv) a field “flags” 2108 and (v) a field “pointers” 2110.

  The field “kind” 2102 of the statement structure 1416 represents the type of statement represented by the statement structure 1416. The field “kind” 2102 identifies one of the following statement types: error, declaration, expression, block, “if”, “else”, “return”, loop, “switch”, “break”, “Continue” and “goto”. The representation of each of these statement types in a statement structure is described in more detail below.

  The field “line” 2104 of the statement structure 1416 shows that the statement represented by the statement structure 1416 appears in the source code file that defines the function represented by the function structure 1400 (FIG. 14), ie, the statement Represents a text line containing a statement represented by structure 1416. The line in which the statement appears is maintained in a statement structure 1416 so that the particular statement that causes the error is identified to the user by notification of the detected error.

  The field “next” 2106 (FIG. 21) of the statement structure 1416 is a pointer that points to another statement structure 2112 that represents the statement immediately following the statement represented by the statement structure 1416 in the block of statements. In this way, all statements in the statement block are represented by statement structures that are linked to form a single linked list. If the statement represented by the statement structure 1416 (FIG. 21) is the last statement in the statement block, the field “next” 2106 is NULL and does not specify another statement structure.

  The field “flags” 2108 of the statement structure 1416 is an unsigned 32-bit integer whose individual bits are used as a flag to indicate whether the user has been notified of an error associated with the statement represented by the statement structure 1416. . Whenever an error is signaled, the flag in the field “flags” 2108 corresponding to the error to be signaled is checked. If the flag is set, no error is signaled because the flag indicates that the error has already been signaled in the context of the statement represented by statement structure 1416. If the flag is not set, an error is notified and the flag is set to reflect the error notification. In this way, each type of error is signaled only once for a particular statement.

  The field “pointers” 2110 of the statement structure 1416 is an array of one or more pointers that specify the structure that represents each part of the statement represented by the statement structure 1416. The number of pointers in this array depends on the particular type of statement represented by statement structure 1416.

  The error, “break”, and “continue” statements have no part, so if the statement structure 1416 represents an error, “break”, or “continue” statement, the field “pointers” 2110 is NULL. An error statement is a statement that does not follow the C language. The “break” and “continue” statements are well known and are described in sections 6.6.6.3 and 6.6.6.2 of the C standard, respectively.

  A declaration statement includes a declared variable that has a particular type of data, and possibly also an initial value for that variable. Therefore, if the statement structure 1416 represents a declaration statement, the field “pointers” 2110 is an array of two pointers. The first pointer specifies a declaration structure that represents the variable being declared. If an initial value is defined, the second pointer points to an expression structure that represents an expression that is evaluated to give the initial value of the declared variable. If no initial value is defined for the declared variable, the second pointer is NULL.

  An expression statement is a statement that is itself an expression. An expression is a known component of the C language, which is a collection of one or more items, calls to functions, and operators. In C language, every expression has a value. The result of evaluating an expression is an item whose value is that of the expression, and this item is often referred to as an expression item. In this specification, the value of an item of an expression is often referred to as an expression value. Expression evaluation is described in more detail below.

When the statement structure 1416 represents an expression statement, the field “pointers” 2110 is an array of one pointer that designates an expression structure such as the expression structure 2200 (FIG. 22). The expression structure 2200 includes a field “kind” 2202, a field “type” 2204, a field “item” 2206, and a field “num”. and "fields" 2210. The field "kind" 2202 identifies the type of expression represented by the expression structure 2200. If the expression includes an operator, the field "kind" 2202 Indicates the operator.

  A field “type” 2204 is a pointer that designates a type structure 2212 that represents the data type of an expression, that is, the type of an item indicating the result of evaluation of the expression. The mold structure 2212 is the same as the mold structure 1612 described above. A field “item” 2206 of the expression structure 2200 is a pointer for designating an item structure 2214 representing an item indicating the result of evaluation of the expression. The item structure 2214 is the same as the item structure 2700 (FIG. 27) described above. Prior to the evaluation of the expression represented by the expression structure 2200, the field “item” 2206 is NULL.

The number of operands in the expression represented by the expression structure 2200 is the field “num The field “operands” 2210 is an array of expression structures, each of which represents one operand of the expression represented by the expression structure 2200. The length of this array is the field “num”. equal to the number of operands shown in "operands" 2208. The various types of expressions defined in the C language, and the number and type of operands for each type of expression, are well known and described in the C standard. .

  A block statement is a statement in which one or more statements are grouped together. Execution of a block statement is the execution of one or more statements. A block statement has parts, ie one or more statements. If the statement structure 1416 (FIG. 21) represents a block statement, the field “pointers” 2110 is a single pointer, which specifies the statement structure that represents the first statement of one or more statements. Statement structures representing one or more statements are linked to form a single linked list by using field “next” 2106 as described above.

  The “if” statement evaluates an expression often referred to as a “if” statement predicate and causes the second statement to be executed if the result of the evaluation is a Boolean value of “true”. If the statement structure 1416 represents an “if” statement, the field “pointers” 2110 is an array of two pointers. The first pointer specifies an expression structure that represents an expression whose value determines whether the second statement is executed. The second pointer specifies a statement structure that represents the second statement.

  The “else” statement is placed immediately after the “if” statement, and if the evaluation of the predicate of the “if” statement is a Boolean value of “false”, the third statement is executed. If the statement structure 1416 represents an “else” statement, the field “pointers” 2110 is an array of two pointers. The first pointer specifies a statement structure that represents the third statement. The second pointer points to an expression structure or is NULL. The expression represented by this expression structure is often referred to as an “else” statement predicate. If the second pointer specifies an expression structure, the third statement has a Boolean value of “false” when the predicate of the “if” statement is evaluated, and a Boolean value of “true” when the predicate of the “else” statement is evaluated. It is executed only when As described and widely known in the C standard, this represents an “else if” statement. If the second pointer is NULL, the third statement is executed only if the predicate evaluation of the “if” statement evaluates to a Boolean value of “false”.

  The “return” statement terminates execution of the called function, transfers control to the calling function, and optionally provides a return value item to the calling function. Giving control to the calling function and giving the calling function a return value item is said to return the return value item to the calling function. If the statement structure 1416 represents a “return” statement, the field “pointers” 2110 is a single pointer, which points to an expression structure or is NULL. If this pointer specifies an expression structure, an item indicating the result of evaluating the expression represented by the expression structure is returned to the calling function.

  The loop statement generates a second statement that is executed zero or more times. Examples of loop statements in the C language are the “for” statement, the “do” statement, and the “while” statement, which are well known and described in section 6.6.5 of the C standard. If the statement structure 1416 represents a loop statement, the field “pointers” 2110 is a single pointer and specifies the statement structure representing the second statement.

  A “switch” statement evaluates an expression and transfers control within a block statement to a specific statement within that block statement in response to a value indicating the result of the expression evaluation. Expressions are often referred to as “switch” statement predicates. If the statement structure 1416 represents a “switch” statement, the field “pointers” 2110 is an array of two pointers. The first pointer specifies an expression structure representing an expression to which control is transferred according to the value. The second pointer specifies a statement structure that represents the block statement.

  The “goto” statement causes a transfer of control to the second statement. In one embodiment, if the statement structure 1416 represents a “goto” statement, the field “pointers” 2110 is an array of single pointers that specify the statement structure representing the second statement. In a more simplified embodiment, the “goto” statement is treated as terminating execution of the called routine. In this example, the “goto” statement has no part, and the field “pointers” 2110 is an array that does not contain pointers.

  In this manner, the function structure 1400 (FIG. 14) represents a function to be analyzed by the dynamic inspection engine 706.

Analysis of Function As described above, the dynamic inspection engine 706 (FIG. 7) analyzes each function structure obtained as a result of parsing the computer program 610 (FIG. 6) in step 908 (FIG. 9). . Step 908 is shown in more detail in logic flow diagram 908 (FIG. 24). In performing step 908, the function structure being processed is referred to as the subject function structure. Similarly, a function represented by a subject function structure is called a subject function. In steps 2404 and 2408 of logic flow diagram 908, the subject function is analyzed under various assumptions.

  As explained in detail above, the control flow path of a particular function often depends on events that are unknown until the function is executed. Even after execution, an event that occurs during the execution of the function does not always occur in all executions of the function. Therefore, the analysis of a function whose control flow depends on unknown events is repeated under various assumptions about those unknown events.

  In one embodiment, all possible control flows of the function are determined and analyzed. For example, control may flow along one of two possible paths for all “if” statements in the function, and multiple possible paths for all “switch” statements in the function. Can flow along one of the In the case of a “switch” statement, the number of possible routes is equal to the number of “case” statements associated with that “switch” statement. This includes "default" statements, if present. Once all possible control flow paths of a function have been determined, the function is repeatedly analyzed so that each control flow path of the function is used once. In this way, the function is analyzed considering all possible events that can affect the control flow of the function.

  In a more simplified embodiment, a particular control flow path of a function is randomly selected by setting random assumptions about the events in each “if” statement and each “switch” statement in the function. The function is iteratively analyzed with various control flow paths selected at random. The number of times the function is analyzed is chosen so that all possible control flow paths of the function are likely to be analyzed, or alternatively, the effort spent analyzing one routine. You can also choose to restrict.

  Steps 2404 and 2408 (FIG. 24) illustrate the latter more simplified embodiment. In step 2404, the number of times the subject function is analyzed is determined. Step 2404 is shown in greater detail as logic flow diagram 2404 (FIG. 25). In step 2502, the number of times the “if” statement is used in the subject function is determined. Specifically, in the single linked list of statement structures specified directly or indirectly by the execution engine 802 (FIG. 8) by the field “first-statement” 1412 (FIG. 14) of the function structure 1400. The field “kind” 2102 (FIG. 21) of each statement structure is compared with the data indicating the “if” statement. The number of times the field “kind” of the statement structure matches the data indicating the “if” statement is recorded as the number of times the “if” statement is used in the subject function.

  From step 2502, the process proceeds to step 2504, where the number of times the subject function is analyzed is determined. In one embodiment, the number of times a subject function is parsed corresponds to the number of times an “if” statement is used in the subject function. An example is shown in Table M.

After step 2504, the process based on logic flow diagram 2404, and thus step 2404 (FIG. 24), ends. The process proceeds from step 2404 to step 2408, where the subject function is repeatedly analyzed for the number determined in step 2404 described above. One iteration of step 2408, ie one analysis of the subject function, is shown in logic flow diagram 2600 (FIG. 26).

  Analysis of one iteration of the subject function begins at step 2602 where the external state structure for each external is initialized. The external state structure first generates an item structure corresponding to the external state structure, ie, corresponding to the external having the state represented by the external state structure, and subsequently the DK and CP states of the external Initialized by setting to state O. The item structure is a structure in the memory 104 (FIG. 1) that represents an item.

Item structure 2700 (FIG. 27) includes the following fields:
That is, field "resource" 2702, field "external" 2704, field "value" 2706, field first in Bunch 2708, field “size” of “bunch” 2710, field “type” code "2712, field" initialized "2714, field" head " in bunch "2716, field" known " bunch size "2718 and the field" invalid " pointer "2720" is included.

  Each item may be associated with a resource and / or an external. If the item represented by the item structure 2700 is associated with one of the resources, the field “resource” 2702 of the item structure 2700 specifies the resource state structure that represents the resource. Conversely, if the item is not associated with a resource, the field “resource” 2702 is NULL to indicate that. If the item represented by the item structure 2700 is associated with one of the externals, the field “external” 2704 of the item structure 2700 specifies an external state structure that represents the external. Conversely, if the item is not associated with an external, the field “external” 2704 is made NULL to indicate that.

The field “value” 2706 of the item structure 2700 contains data that defines the actual value of the item represented by the item structure 2700. That is, the data stored in the field “value” 2706 is the actual data stored at the position designated by the item represented by the item structure 2700 (FIG. 27) in the memory 104 (FIG. 1). Express. Field “type” of item structure 2700 “code” 2712 specifies the type of data stored in the memory location of the item. The types of data supported in the embodiments disclosed herein include long, pointer, and double. In the language implementation, “long” is a 32-bit signed integer, “pointer” is a value that specifies an address in a memory such as the memory 104, and “double” is a 64-bit floating point. Within value “2706” there are subfields corresponding to the type of each data. Only one subfield is used, ie the field “type”. Only the subfield corresponding to the data type designated by “code” 2712 is used.

The field “initialized” 2714 of the item structure 2700 indicates whether the item represented by the item structure 2700 has been initialized, that is, whether the item represented by the item structure 2700 has a known value. Indicates. Field “invalid” of item structure 2700 Pointer “2720” indicates whether or not the item represented by the item structure 2700 is an invalid pointer. In the C language, when the pointer specifies a valid position in the memory 104 (FIG. 1), The pointer is valid, otherwise the pointer is invalid, a NULL pointer is a specific invalid pointer that is selected to 0 in many implementations of C. In one embodiment, the field "initialized""2714" and "invalid Each pointer “2720” is composed of one bit.

Field "first" in “bunch” 2708, “size” of “bunch” 2710, “head” in Bunch ”2712 and“ known ” bunch The size “2718” is used to analyze a memory cluster. The memory cluster will be described in detail later.

  In step 2602 (FIG. 26), once the subject function external is initialized, the process proceeds to step 2604. In step 2604, each statement of the subject function is evaluated. A statement is evaluated by emulating the execution of that statement. The evaluation of the statement provides the result of the operation performed on the external and / or resource, resulting in a change in the respective state of the external and / or resource. As will be described in detail later, evaluation of each statement is performed individually according to logic flow diagram 2800 (FIG. 28).

  Once each statement of the subject function is evaluated, processing proceeds from step 2604 (FIG. 26) to step 2606. In step 2606, leaks of various resource states of the subject function are checked. Details of step 2606 are shown in logic flow diagram 2606 (FIG. 41), which will be described later. From step 2606, processing proceeds to step 2608 where each external of the subject function is updated. The external update is performed by updating the external composite DK, CP, and RS state based on the external DK and CP state and the RS state of the resource associated with the external. These states are obtained from the current iterative analysis of the subject function. One external update is shown in logic flow diagram 4200 (FIG. 42) and will be fully described below.

When step 2608 (FIG. 26) is completed, the process according to the logic flow diagram 2600, that is, one iteration of the subject function, is completed.
Statement Evaluation As described above, each statement of the subject function is evaluated individually according to logic flow diagram 2800 (FIG. 28). Processing begins at test step 2802, where the execution engine 802 (FIG. 8) causes the statement “struct” field “kind” 2102 (FIG. 21) to represent the statement, ie the structure of the subject statement. By searching, it is determined whether the statement is an expression. The statement is a subject statement represented by a subject statement structure. That is, the statement being evaluated according to the logic flow diagram 2800 (FIG. 28) at that time is referred to as a subject statement.

  If the subject statement is an expression, ie, the field “kind” 2102 indicates that the subject statement is an expression, processing proceeds from test step 2802 (FIG. 28) to step 2804 where the execution engine 802 (FIG. 8) evaluates an expression, ie a subject statement. The execution engine 802 evaluates the expression by emulating the execution of functions and operators on the items included in the expression. Step 2804 (FIG. 28) is performed according to logic flow diagram 2900 (FIG. 29), which will be described in detail later.

  As will be described in detail later, the process according to logic flow diagram 2900 may perform operations on items obtained as a result of expression evaluation. In the context of step 2804, there is no operation performed on the expression item. At test step 2802 (FIG. 28), if the subject statement is not an expression, processing proceeds to test step 2806.

  In test step 2806, the execution engine 802 (FIG. 8) compares the field “kind” 2102 of the subject statement structure with data indicating that the subject statement is a declaration. The defining declaration is a statement according to the C language that generates an item. The declaring declaration is a statement according to the C language that instructs the CPU 102 (FIG. 1) to handle the item as if it were a specific type. In cases other than those described here, the declaration is a defining declaration. If the subject statement is a declaration, processing proceeds from test step 2806 (FIG. 28) to step 2808 where the declaration is processed. This will be described in detail later. Conversely, if the subject statement is not a declaration, processing proceeds from test step 2806 to test step 2810.

  In test step 2810, execution engine 802 (FIG. 8) retrieves the field “kind” 2102 (FIG. 21) of the subject statement structure and data indicating that the subject statement is an “if” statement. Compare. If the statement is an “if” statement, processing proceeds from test step 2810 (FIG. 28) to step 2812 where the subject statement is processed. Step 2812 is shown in more detail in the logic flow diagram 2812 (FIG. 35) described below. Conversely, if the subject statement is not an “if” statement, processing proceeds from test step 2810 (FIG. 28) to test step 2814.

In the test step 2814, the execution engine 802 (FIG. 8) performs the field “kind” 2102 (FIG. 21) of the subject statement structure.
And data indicating that the subject statement is a “return” statement. If the subject statement is a “return” statement, processing proceeds from test step 2814 (FIG. 28) to step 2816, where the statement is processed. Step 2816 is shown in more detail in the logic flow diagram 2816 (FIG. 39) described below. Conversely, if the subject statement is not a “return” statement, processing proceeds from test step 2814 (FIG. 28) to test step 2818.

  In test step 2818, execution engine 802 (FIG. 8) retrieves the subject statement field “kind” 2102 (FIG. 21) and data indicating that the subject statement is a loop or block statement. Compare. If the subject statement is a loop or block statement, processing proceeds from test step 2818 (FIG. 28) to step 2820, where the statement is processed. Step 2820 is shown in more detail in the logic flow diagram 2820 (FIG. 40) described below. Conversely, if the subject statement is neither a loop statement nor a block statement, processing proceeds from test step 2818 (FIG. 28) to test step 2822.

  In test step 2822, execution engine 802 (FIG. 8) compares subject statement field “kind” 2102 (FIG. 21) with data indicating that the subject statement is a “goto” statement. To do. If the subject statement is a “goto” statement, processing proceeds from test step 2822 (FIG. 28) to step 2824, where execution engine 802 (FIG. 8) provides “return” as detailed below. Data indicating the condition is stored in the control record. This control record is used to provide an appropriate control flow when emulating the execution of the subject function, as will be described in detail later. The “return” condition terminates the iterative analysis of the subject function.

  If the subject statement is not a “goto” statement, processing ends according to logic flow diagram 2800.

  After any of steps 2804, 2808, 2812, 2816, 2820, or 2824 are performed, processing ends according to logic flow diagram 2800. Thus, the evaluation of a statement by the execution engine 802 (FIG. 8) is whether the statement is an expression, a declaration, an “if” statement, a “return” statement, or a block statement. Depending on whether it is a loop statement or a “goto” statement, it is performed in step 2804 (FIG. 28), step 2808, 2812, 2816, 2820, 2824, or 2828, respectively.

Expression Evaluation As described above, expressions are evaluated according to logic flow diagram 2900 (FIG. 29), where execution engine 802 (FIG. 8) uses state machine 804, which is part of dynamic inspection engine 706. If there is an operation designated by the execution engine 802, the operation is applied to the item of the expression. As described above, in the context of step 2804 (FIG. 28), execution engine 802 (FIG. 8) does not specify such an operation. In the embodiments of the present invention disclosed herein, an expression is evaluated to determine the effect of executing a statement that is an expression or a statement that includes an expression on an item that is an operand of the expression.

  Processing according to logic flow diagram 2900 (FIG. 29) begins at step 2902 where processing specified by an operator in the expression is performed to evaluate the expression. As described above, expressions are represented in the dynamic inspection engine 706 (FIG. 7) by an expression structure such as an expression structure 2200 (FIG. 22). The field “kind” 2202 of the expression structure 2200 specifies the type of operator of the expression, and the field “operands” 2210 includes an operand on which the operation of the operator is performed.

  Since the analysis of the subject function is performed in the context of execution of the subject function in a computer process, the initial value of the subject function external is unknown. Therefore, the expression in this subject function need not evaluate to a known value. Accordingly, when the expression is evaluated by the execution engine 802 (FIG. 8) in step 2902 (FIG. 29), a known or partially known value is generated by the evaluation of the expression. Otherwise, a NULL is generated. As will be described in detail later, an item may have a “partially known” value. For example, it can be known that an item has a non-zero value, but the exact value of the item is not yet known, in which case the value of that item is “partially known”. Step 2902 is detailed in logic flow diagram 2902 (FIGS. 33a, 33b, 33c, 33d, and 33e) and will be described in detail later. From step 2902 (FIG. 29), processing proceeds to test step 2904 where the execution engine 802 (FIG. 8) determines whether the expression has generated an item instead of NULL and whether the state machine 804 It is determined whether an operation is performed on the item. If no item is generated by the evaluation of the expression, or if no operation is performed on the item, the process proceeds from test step 2904 (FIG. 29) to step 2908 described later. Conversely, if an item is generated by the evaluation of the expression and an operation is performed on the item, the process proceeds from test step 2904 to step 2906, where state machine 804 (FIG. 8) operates on the item. Apply.

  In order to perform an operation on an item of the evaluated expression, when an external and a resource are associated with the item, the state machine 804 performs an operation on the external and the resource associated with the item. For example, the field “external” 2704 of the item structure 2700 (FIG. 27) specifies an external state structure that represents an external associated with the item represented by the item structure. Similarly, the field “resource” 2702 of item structure 2700 specifies a resource state structure that represents the resource associated with the item.

  The operations performed on the external include, for example, updating the fields “DK” 3004 (FIG. 30) and “CP” 3008 of the external state structure 3000. The external state structure 3000 is an external state structure that represents the external. The update of the field “DK” 3004 is performed according to the operation performed on the external and according to the state diagram 500 (FIG. 5a) described above. For example, when the field “DK” 3004 (FIG. 30) indicates the state O and the operation m is performed on the external, the field “DK” 3004 is updated to indicate the state Q. The update of the field “CP” 3008 is performed according to the state diagram 400 (FIG. 4a).

  The operation performed on the resource includes, for example, updating the fields “state” 3102 (FIG. 31) and “modified” 3108 of the resource state structure 3100. This resource state structure is a resource state structure that represents the resource. The field “state” 3102 is updated according to the state diagram 300 (FIG. 3A) described above. The field “modified” 3108 (FIG. 31) is updated by storing data specifying the current row in the field “modified” 3108 to indicate the statement that last modified the resource. The current line refers to the line on the computer program 610 (FIG. 6) where the subject statement exists. Informing the user of programming errors associated with the resource and presenting to the user the statement that last modified the resource helps the subject function developer to remove the programming error.

  As will be described in detail later, by updating the field “DK” 3004 (FIG. 30) or “CP” 3008 of the external state structure 3000, or updating the field “state” 3102 (FIG. 31) of the resource state structure 3100. If an error based on state diagram 300, 400, or 500 (FIGS. 3A, 4 and 5) occurs, the user is notified of this error. Items generated by expression evaluation can also be checked for state violations based on the logic flow diagram 3200 (FIG. 32).

  In test step 3202 (FIG. 32), state machine 804 (FIG. 7) examines field “initialized” 2714 (FIG. 27) of item structure 2700 and the item represented by item structure 2700 is initial. It is determined whether or not If the item has not been initialized, processing proceeds from test step 3202 (FIG. 32) to step 3204 where an error is reported. Since the execution of each step of the logic flow diagram 3200 is executed only within the step 2906 (FIG. 29), the operation is performed on items in the logic flow diagram 3200 (FIG. 32). Thus, when the item is initialized, it is used before it is initialized, as shown by the application of the operation, which results in an error.

If the item is initialized, processing proceeds from test step 3202 to test step 3206. In test step 3206, state machine 804 (FIG. 8) performs field “invalid” of item structure 2700. The pointer "2720" (FIG. 27) is checked to determine whether or not the item is an invalid pointer, and the operation to be performed is compared with the operation i, that is, the indirect operation. The item is a valid pointer. When the operation i is performed, the process proceeds to step 3208 (FIG. 32), where an error is notified, and conversely, the item is not a valid pointer or an operation other than the operation i is performed. If so, processing proceeds from step 3206 to test step 3210.

  In test step 3210, state machine 804 (FIG. 7) determines whether the item is an invalid pointer, as described above with respect to test step 3206, and compares the operation to be performed with operation k. To do. In the context of the C language, releasing an invalid pointer is an error because library functions can corrupt the data structures used to manage files and dynamically allocated memory. Generally, it is not an error to release a NULL pointer, but it is generally considered as an inadequate program creation method and is notified as an error.

  If the item is an invalid pointer and operation k is performed on the item, the process proceeds to step 3212 where an error is notified. Conversely, if the item is not an invalid pointer or an operation other than operation k is performed, processing ends according to logic flow diagram 3200. Also, after steps 3204, 3208, and 3212 are complete, processing ends according to logic flow diagram 3200.

Therefore, in step 2906 (FIG. 29), an operation is performed on the item and its associated resource or external, and any error is detected and notified to the user. From step 2906, processing proceeds to step 2908. If there is no item generated by the evaluation of the expression, or if there is no operation performed on the expression as described above, the process proceeds directly from the test step 2904 to step 2908. In step 2908, the execution engine 802 includes an expression, ie, a subject statement, and further includes an item if an item is generated, or an item whose value is NULL if it is not generated. It is out. More specifically, the execution engine 802 stores a pointer for designating the item in the field “item” 2206 (FIG. 22) of the expression structure 2200 representing the subject statement. Therefore, in the subsequent evaluation of the expression, the item is simply returned to the part specified by the field “item” 2206, thereby avoiding redundant processing. After step 2908 (FIG. 29), processing ends according to logic flow diagram 2900.
Constants As described above, in step 2902 (FIG. 29), shown in detail in logic flow diagram 2902 (FIGS. 33A-33E), execution engine 802 (FIG. 8) is controlled by an operator in the expression. Process the expression as specified. The execution engine 802 processes the expression according to the type of operation. In test step 3301 (FIG. 33A), processing begins according to logic flow diagram 2902, where execution engine 802 (FIG. 8) does not include an operator, but instead includes a constant. It is determined whether or not. If the expression structure 2200 (FIG. 22) expresses the expression of the subject statement, the execution engine 802 (FIG. 8) will return the field “kind” 2202 (FIG. 22) of the expression structure 2200 and the expression This determination is made by comparing with data indicating that is a constant. A constant is an item whose value does not change during the execution of a computer process. For example, the expression “10” is an integer and a constant whose value is always 10.

  If the expression is not a constant, the process proceeds to test step 3303 (FIG. 33A) described later. Conversely, if the expression is a constant, processing proceeds from test step 3301 to step 3302. In step 3302, the execution engine 802 (FIG. 8) generates an item structure that represents a constant, and initializes the item structure to have the value of the constant. After step 3302 ends, processing ends according to logic flow diagram 2902 and step 2902 (FIG. 29).

Like the variable described above, if the expression is not a constant, the process proceeds from test step 3301 (No. 33A charts) to test step 3303. In test step 3303, execution engine 802 (FIG. 8) compares the field “kind” 2202 (FIG. 22) of the expression structure representing the expression with data indicating that the expression is a variable. To determine whether the expression is a variable. An expression that is a variable evaluates to the current item value of that variable's item. For example, if the previously processed statement of the subject function declares a variable whose identifier is “i”, ie, type “int”, ie, variable “i” that is an integer, the expression “i” is The current item value of the item of variable “i” is evaluated. If the expression is not a variable, the process proceeds to test step 3305 (FIG. 33A) described later. Conversely, if the expression is a variable, processing proceeds from test step 3303 to step 3304.

In step 3304, the execution engine 802 (FIG. 8) searches for the item of the variable i. When the expression structure 2300 (FIG. 23) expresses the expression, that is, when a variable is expressed, (i) the field “num” The “operands” 2308 has a value 1 designating one operand, and (ii) the field “operands” 2310 is an array of one pointer designating the declaration structure 2310. The field “item” of the declaration structure 2316 2324 is retrieved as the value of the expression 2300. If there is no item associated with the declaration structure 2316, the field “item” 2324 will be NULL, so either the existing item structure or NULL. Is taken out in step 3304 (Fig. 33A) After step 3304, processing ends according to logic flow diagram 2902 or step 2902 (Fig. 29).

Binary Operator As described above, if the expression is not a declaration, processing proceeds from test step 3303 (FIG. 33A) to test step 3305. In test step 3305, the execution engine 802 (FIG. 8) compares the field “kind” 2202 (FIG. 22) of the expression structure representing the expression with the data indicating the binary operator to It is determined whether or not the operator of the expression is a binary operator. The binary operator is an operator that performs an operation on two operands and is not a relational operator. For example, the expression “a + b” includes a binary operator “+” that specifies addition. Relational operators will be described later.

  If the operator of the expression processed according to logic flow diagram 2902 (FIG. 33A) is not a binary operator, processing proceeds from test step 3305 to test step 3309. Conversely, if the expression operator is a binary operator, processing proceeds from test step 3305 to step 3306. In step 3306, the left operand, "lhs", is evaluated as an expression according to logic flow diagram 2900 (FIG. 29). An expression lhs having two operands and represented by an expression structure 2200 (FIG. 22) is represented by an expression structure that is the first element of the field “operands” 2210. This lhs is evaluated according to the logic flow diagram 2900 (FIG. 29) and subjected to operation C. Performing operations according to logic flow diagram 2900 has been described previously. Accordingly, the evaluation of the expression according to logic flow diagram 2900 is iterative. In other words, evaluation of an expression according to the logic flow diagram 2900 can also evaluate a subexpression of the expression according to the logic flow diagram 2900. Such recursive programming is a well-known technique.

  A binary operator has a right operand, or “rhs”, along with a left operand. For example, the expression “(a + b) * c” has lhs “(a + b)” and rhs “c”. This is because the highest priority in this expression is the operator “*”, that is, the multiplication operator. The rhs of the expression having two operands and represented by the expression structure 2200 (FIG. 22) is represented by the expression structure of the second element of the field “operands” 2210. After the expression lhs is evaluated in step 3306 (FIG. 33A), processing proceeds to step 3307 where the execution engine 802 (FIG. 8) determines the rhs of this expression according to logic flow diagram 2900 (FIG. 29). While performing evaluation, the calculation c is performed. The operation c is applied to both lhs and rhs of the formula because each is used in the calculation. In such a calculation, if either lhs or rhs of the expression is inappropriately used, an error message is generated by performing the calculation as described above.

  From step 3307 (FIG. 33A), processing proceeds to step 3308 where the expression is evaluated using the binary operator of the expression. The type of lhs and rhs data in this expression affects the type of operation invoked by the operator. In the C language, the types of operations that specific operators perform on specific types of operands are well known and described in section 6.3 of the C standard.

  Expression operators are applied to the operands of the expression according to a predetermined operator application method described in the C standard. For example, if the operator is an arithmetic addition operator (ie, “+”), applying the operator to two operands results in an arithmetic sum of the two operands. As a second example, if the operator is a relational operator (ie, “>”) indicating that one value is greater than the other, this operator is divided into two operands, ie, lhs and rhs. By applying, a Boolean value “true” is obtained if the value of lhs is greater than the value of rhs, and a Boolean value “false” is obtained in the opposite case.

  For the resource checker 602 (FIG. 6) to detect improper use of resources in the computer program 610, it is not necessary that all C language operators are properly applied by the execution engine 802 (FIG. 8). Absent. If the expression contains an operator that cannot be applied by the execution engine 802 (FIG. 8), the expression is evaluated to NULL, indicating that evaluation of the expression produces an item with an unknown value. However, it is preferable that the execution engine 802 can apply as many C language operators as possible to properly improve the inappropriate use of resources detected by the resource checker 602.

  After step 3308 (FIG. 33A), processing ends according to logic flow diagram 2902, step 2902 (FIG. 29).

Relational Operator As noted above, if the expression operator is not a binary operator, processing proceeds from test step 3305 (FIG. 33A) to test step 3309. In test step 3309, execution engine 802 (FIG. 8) determines whether the operator of the expression is a relational operator. The relational operator is an operator that performs an operation on two operands, i.e., lhs and rhs, and generates an item having a numerical value corresponding to a Boolean value obtained by comparing the values of the two operands. The Boolean value is either “true” or “false”. Specific examples of relational operators include “==” (equal), “> =” (larger or equal), “<=” (smaller or equal), and “! =” (Not equal). .

  If the operator of this expression is not a relational operator, the process proceeds from test step 3309 (FIG. 33A) to test step 3313 described later. Conversely, if the expression operator is a relational operator, processing proceeds from test step 3309 to step 3310. In step 3310, execution engine 802 (FIG. 8) evaluates expression lhs as an expression according to logic flow diagram 2900 (FIG. 29) and applies operation p. From step 3310 (FIG. 33A), processing proceeds to step 3311, where execution engine 802 (FIG. 8) evaluates rhs of the expression and applies operation p according to logic flow diagram 2900 (FIG. 29). To do. The operation p applies to both lhs and rhs in the expression because each is used for comparison. In such a comparison process, if either lhs or rhs in the expression is used inappropriately, an error message is generated by applying the calculation as described above.

  Processing proceeds from step 3311 (FIG. 33A) to step 3312, where the relational operator of the expression is used to evaluate the expression. Step 3312 is similar to step 3302 described previously. After step 3312 ends, processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Unary operator As noted above, if the operator in this expression is not a relational operator, processing proceeds from test step 3309 (FIG. 33A) to test step 3313. In the test step 3313, the execution engine 802 (FIG. 8) determines whether or not the operator of the expression is a unary operator, the field “kind” 2202 (FIG. 22) of the expression structure representing the expression. And the data indicating the unary operator. A unary operator is an operator that specifies an operation having only one operand. For example, the expression “−a” has only one operand “a” and a unary operator “−” that specifies an operation that makes a numerical value negative with respect to the operand “a”. If an expression has one operand and is represented by an expression structure 2200, only one operand of the expression is represented by an expression structure that is the first element of the field “operands” 2210. The

  If the operator of the expression is not a unary operator, the process proceeds from test step 3313 (FIG. 33B) to test step 3313 (FIG. 33B) described later. Conversely, if the expression operator is a unary operator, processing proceeds from test step 3313 (FIG. 33B) to step 3314. In step 3314, execution engine 802 (FIG. 8) evaluates the operands of the expression as an expression according to logic flow diagram 2900 (FIG. 29) and applies operation c. The operation c is applied to the operand of the expression because this operand is used in the calculation. If an expression operand is used inappropriately in such a calculation, an error message is generated by applying the operation as described above.

  Processing proceeds from step 3314 (FIG. 33B) to step 3315, where the unary operator of the expression is used to evaluate the expression. Step 3315 is similar to step 3308 described above. After step 3315 ends, processing ends according to logic flow diagram 2902, step 2902 (FIG. 29).

Processing by Specific Operator As described above, when the operator of the expression is not a unary operator, the processing proceeds from test step 3313 (FIG. 33B) to test step 3317 (FIG. 33B). As further described above, in the above-described steps in logic flow diagram 2902, processing of the expression is performed according to the type of operator of the expression. Executed in the test step 317 and subsequent steps if the expression operator type is not among the operator types determined in the test step 3301 (FIG. 33A), 3303, 3305, 3309 and 3313 Engine 802 (FIG. 8) processes the expression according to a specific operator of the expression.

In an increment or decrement operator step 3317 (FIG. 33B), the execution engine 802 (FIG. 8) compares the expression operator with the increment and decrement operators. That is, when the expression structure 2200 (FIG. 22) expresses the expression, the execution engine 802 includes the field “kind” 2202 (FIG. 22), data specifying an increment operator or a decrement operator, Compare The increment operator or decrement operator performs an operation to increase / decrease the operand one by one. If the operator of the expression is neither an increment operator nor a decrement operator, the process proceeds to test step 3320 (FIG. 33B) described later. Conversely, if the expression operator is an increment operator or a decrement operator, processing proceeds from test step 3317 to step 3318.

  In step 3318, execution engine 802 (FIG. 8) evaluates its operands according to logic flow diagram 2900 (FIG. 29) and applies operation c. The operation c is applied because this operand is used in the calculation. As described above, any error caused by applying operation c to its operand is detected and notified.

  Processing proceeds from step 3318 (FIG. 33B) to step 3319, where the expression is evaluated using an increment or decrement operator. Step 3319 is similar to Step 3308 (FIG. 33A) described above. After step 3319 (FIG. 33B), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

“Not” operator As described above, if the operator of the expression is neither an increment operator nor a decrement operator, processing proceeds from test step 3317 (FIG. 33B) to test step 3320. In test step 3320, execution engine 802 (FIG. 8) compares field “kind” 2202 (FIG. 22) of the expression structure representing the expression with data specifying the “Not” operator. The C language “Not” operator is compared with the expression operator. The “Not” operator operates on only one operand and treats the operand itself as a Boolean item to generate an item having a value corresponding to the Boolean value of the logical negation of the operand. A Boolean item is an item having a value corresponding to either a Boolean value of true or false.

  If the operator of the expression is not a “Not” operator, processing proceeds from test step 3320 (FIG. 33B) to test step 3323. Conversely, if the expression operator is a “Not” operator, processing proceeds from test step 3320 to 3321. In step 3321, execution engine 802 (FIG. 8) evaluates operands and performs operation p in accordance with logic flow diagram 2900 (FIG. 29). The operation p is performed because this operand is used to perform a truth value calculation. As described above, all errors caused by applying the operation p to the operand are notified.

  Processing proceeds from step 3321 (FIG. 33B) to step 3322, where the “Not” operator is used to evaluate the expression. Step 3322 is similar to step 3308 (FIG. 33A) described previously. After completion of step 3322 (FIG. 33B), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

“And” Operator and “Or” Operator As described above, when the operator of the expression is not the “NOt” operator, the process proceeds from the test step 3320 (FIG. 33B) to the test step 3323. In the test step 3323, the execution engine 802 (FIG. 8) specifies the field “kind” 2202 (FIG. 22) of the expression structure representing the expression, the “And” operator and the “Or” operator. By comparing the data, the C language “And” operator and “Or” operator are compared with the expression operators. The "And" operator and the "Or" operator operate on two operands, ie, lhs and rhs, treat the operand as a Boolean item, and have a logical product of the Boolean values and a Boolean value of the logical sum. Is generated.

  If the expression operator is neither the “And” operator nor the “Or” operator, processing proceeds from test step 3323 (FIG. 33B) to test step 3327. Conversely, if the expression operator is an “And” operator or an “Or” operator, processing proceeds from test step 3323 to step 3324.

  In step 3324, execution engine 802 (FIG. 8) evaluates lhs of the expression as the expression itself and performs operation p in accordance with logic flow diagram 2900 (FIG. 29). From step 3324 (FIG. 33B), processing proceeds to step 3325, where execution engine 802 (FIG. 8) evaluates rhs of the expression according to logic flow diagram 2900 (FIG. 29) and applies operation p. To do. The operation p is applied to both lhs and rhs of the formula because each is used for truth value calculation. If either of the expressions lhs or rhs is used inappropriately in such a truth value calculation, an error message is generated by applying the operation p as described above.

  Processing proceeds from step 3325 (FIG. 33B) to step 3326 where the expression “And” or “Or” is used to evaluate the expression. Step 3326 is similar to Step 3308 (FIG. 33A) described above. After completion of step 3326 (FIG. 33B), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Compound Operator As described above, if the operator of the expression is neither the “And” operator nor the “Or” operator, the process proceeds from the test step 3323 (FIG. 33B) to the test step 3327. In the test step 3327, the execution engine 802 (FIG. 8) determines whether or not the operator of the expression is a compound operator, and whether or not the field “kind” 2202 ( The determination is made by comparing FIG. 22) with the data specifying the compound operator. In the C language, a compound operator, that is, a comma (“,”) performs an operation on two operands, that is, lhs and rhs of an expression, and generates an item having a value obtained by evaluating rhs as an operation result. That is, the two operands are evaluated individually, and the value obtained by evaluating the rhs of the expression becomes the value of the expression.

  If the expression operator is not a compound operator, processing proceeds from test step 3327 (FIG. 33C) to test step 3330. Conversely, if the expression operator is a compound operator, processing proceeds from test step 3327 to step 3328. In step 3328, execution engine 802 (FIG. 8) evaluates the expression lhs as that expression according to logic flow diagram 200 (FIG. 29) and does not apply the operation. From step 3328 (FIG. 33C) processing proceeds to step 3329 where execution engine 802 (FIG. 8) evaluates rhs of the expression according to logic flow diagram 2900 (FIG. 29). According to logic flow diagram 2900, the operations performed when evaluating an expression containing a compound operator are similar to the operations performed on rhs when evaluating rhs in step 3329 (FIG. 33C). Items generated by evaluating rhs of an expression are returned as items of the expression itself.

  After step 3329 (FIG. 33C), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Indirect Operator As noted above, if the operator of the expression is not a compound operator, processing proceeds from test step 3327 (FIG. 33C) to test step 3330. In the test step 3330, the execution engine 802 (FIG. 8) determines whether the operator of the expression is an indirection operator or not, the field “kind” 2202 of the expression structure that represents the expression (second figure). 22) and the data designating the indirect operator are compared. In the C language, an indirect operator (ie, “*”) performs an operation on one operand, and the result is stored at the address specified by that operand in memory, ie, memory 104 (FIG. 1). Generate an item with the specified value. For example, the expression “* a” evaluates an item having a value stored at the address “a” in the memory. Indirect operators can also be used to refer to elements of an array. For example, the declaration “int The second element of the array defined by array [10] ”can be specified by either“ array [1] ”or“ * (array + 1). ”The latter expression is an array of the size of the elements of the array The value stored in the relative position (offset) 1 when the starting point is 0, that is, the value of the second element of the array is referred to.

  If the operator of the expression is not an indirect operator, processing proceeds from test step 3330 (FIG. 33C) to test step 3335. Conversely, if the operator of the expression is an indirect operator, processing proceeds from test step 3330 to test step 3331.

  In test step 3331, execution engine 802 (FIG. 8) determines whether the operand is an array. If the expression structure 2220 (FIG. 22) represents the operand, the field “type” 2204 (FIG. 22) specifies the type structure that specifies the type of the operand. For example, if the type structure 1612 (FIG. 17) is specified by the field “type” 2204 (FIG. 22) of the expression structure 2220, the execution engine 802 (FIG. 8) has its operand as an array. It is determined by comparing the field “kind” 1702 (FIG. 17) with the data specifying the array.

  If the operand is an array, processing proceeds from test step 3331 (FIG. 33C) to step 3332, where execution engine 802 (FIG. 8) executes the operand according to logic flow diagram 2900 (FIG. 29). Is evaluated as an expression and no operation is applied, but the operator is treated as an array indirect addressing means, ie as a reference element of one element of an array of the type "* (array + 1)" described above. Conversely, if the operand is not an array, processing proceeds from test step 3331 (FIG. 33C) to step 3333, where execution engine 802 (FIG. 8) performs its expression according to logic flow diagram 2900 (FIG. 29). And the operation i is applied, and the operator is treated as a pointer for specifying an indirect address, that is, for the above-described expression “* a”.

  Processing proceeds from either step 3332 (FIG. 33C) or step 3333 to step 3334, where execution engine 802 (FIG. 8) dereferences the operand. In operand dereferencing, the expression specified by the operand is generated by evaluating the expression. If the operand does not specify an item, the expression evaluates to NULL. After step 3334 (FIG. 33C), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Component Reference Operator As noted above, if the expression operator is not an indirect operator, processing proceeds from test step 3330 (FIG. 33C) to test step 3335. In the test step 3335, the execution engine 802 (FIG. 8) determines whether the operator of the expression is a component reference operator or not, the field “kind” 2202 (22nd expression) of the expression structure representing the expression. Figure) and the data specifying the component reference operator. In the C language, the component reference operator (ie, “.” Or “->”) operates on two operands, ie, lhs and rhs of an expression, and the result of lhs specified by rhs as the result of the operation Generate field items. For example, the declaration “struct {int a; char * b} c, * d” declares the item “c” and the pointer “d” to the second item, each of which has the data type “ Int ”, that is, the first field item“ a ”of integer and the data type is“ char ”, that is, the second field item“ b ”designating data that is a character. The expression “c.a” evaluates to an integer field item of item “c”. Similarly, the expression “d-> a” evaluates to the integer field item of the item specified by the pointer “d”.

  If the expression operator is not a component reference operator, processing proceeds from test step 3335 (FIG. 33C) to test step 3338 (FIG. 33D). Conversely, if the expression operator is a component reference operator, processing proceeds from test step 3335 (FIG. 33C) to step 3336.

  In step 3336, execution engine 802 (FIG. 8) evaluates the expression lhs according to logic flow diagram 2900 (FIG. 29) and no operation is performed. From step 3336 (FIG. 33C), processing proceeds to step 3337, where execution engine 802 (FIG. 8) retrieves the field specified by the expression rhs. After step 3337 ends, processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Array Reference Operator As described above, if the expression operator is not a component operator, processing proceeds from test step 3335 (FIG. 33C) to test step 3338 (FIG. 33D). In the test step 3338, the execution engine 802 (FIG. 8) determines whether the expression operator is an array reference operator or not, the field “kind” 2202 (FIG. 22) of the expression structure representing the expression. And comparison with data specifying the array reference operator. In the C language, an array reference operator (that is, “[]”) performs an operation on two operands, that is, lhs and rhs of the expression, and as an operation result, an element of an array of lhs specified by rhs Is generated. For example, the declaration “int array [10] "declares an array of 10 integers. The expression" array [b] "is an integer element that exists at the position specified by the item" b "in the array" array ". The item “b”, or rhs, is sometimes referred to as an index.

  In the C language, the array reference operator can also be used to reference an offset from a non-array pointer. For example, if “datum” is a variable of type “int”, the expression “datum [2]” is offset by two memory locations from the item representing the variable “datum” in the memory 104 (FIG. 1). It evaluates to the data stored at the location. The two memory locations are equal to the length of the variable “datum”, ie the length of two variables of the data type “int”. As described above, in the context of C language, “array [i]” and “* (array + i)” are equivalent expressions (see sections 6.3 and 2.1 of the C standard).

  If the operator of the expression is not an array reference operator, processing proceeds from test step 3338 (FIG. 33D) to test step 3344. Conversely, if the operator of this expression is an array reference operator, processing proceeds from test step 3338 to step 3339.

  In step 3339, the execution engine (FIG. 8) evaluates the index of the expression according to the logic flow diagram 2900 (FIG. 29) and performs the operation c. The calculation c is performed because this index is used for calculation. From step 3339 (FIG. 33D), processing proceeds to test step 3340, where execution engine 802 (FIG. 8) determines whether lhs is an array in relation to test step 3331 (FIG. 33C). Judgment is made by the method described above. If lhs is an array, processing proceeds from test step 3340 (FIG. 33D) to step 3341, where execution engine 802 (FIG. 8) determines the rhs of the expression according to logic flow diagram 2900 (FIG. 2). Is used as an index. At this time, no operation is performed. Conversely, if lhs is not an array, processing proceeds from test step 3340 (FIG. 33D) to step 3342, where execution engine 802 (FIG. 8) has its expression according to logic flow diagram 2900 (FIG. 29). Evaluate rhs as a pointer and perform operation i.

  Processing proceeds from either step 3341 (FIG. 33D) or step 3342 to step 3343, where the execution engine 802 (FIG. 8) searches for the element specified by rhs in the array specified by lhs. To do. After completion of step 3343 (FIG. 33D), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Address Operator As described above, if the operator of the expression is not an array operator, processing proceeds from test step 3338 (FIG. 33D) to test step 3344. In test step 3344, execution engine 802 (FIG. 8) determines whether the operator of the expression is an address operator, field “kind” 2202 of the expression structure that represents the expression, and address calculation. Judgment is made by comparing the data specifying the child. In the C language, the address operator (that is, “&”) performs an operation on one operand, and generates an item whose operand address is the value as the operation result. For example, the expression “& a” is evaluated as an item whose value is an address in the memory, that is, the memory 104 in which the item “a” is stored.

  If the operator of the expression is not an address operator, processing proceeds from test step 3344 (FIG. 33D) to test step 3347. Conversely, if the operator of the expression is an address operator, processing proceeds from test step 3344 to step 3345.

  In step 3345, execution engine 802 (FIG. 8) evaluates the operands according to logic flow diagram 2900 (FIG. 29), at which time no other operation is performed. From step 3345 (FIG. 33D), processing proceeds to test step 3346 where the address operator is used to evaluate the expression. That is, the address of the operand is determined. Step 3346 is similar to previously described step 3308 (FIG. 33A). After step 3346 (FIG. 33D) ends, processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Invocation of a function As described above, if the operator of the expression is not an address operator, processing proceeds from test step 3344 (FIG. 33D) to test step 3347. In the test step 3347, the execution engine 802 (FIG. 8) determines whether the operator of the expression is a function call or not, the field “kind” 2202 (FIG. 22) of the expression structure representing the expression. ) And data specifying a function call. In the C language, a function operator (i.e., "()") means a function call. A function call is evaluated in the returned item of the function. For example, the expression “abc ()” calls execution of a function whose identifier is “abc”. Similarly, the expression “xyz (d, e, f)” calls a function whose identifier is “xyz” and items d, e, and f are given as parameters.

If the expression operator is not a function call, processing proceeds from test step 3347 (FIG. 33E) to test step 3353. Conversely, if the expression operator is a function call, processing proceeds from test step 3347 to loop step 3348. Loop step 3348, step 3349, and NEXT step 3350 form a loop in which each parameter is evaluated. In step 3349, execution engine 802 (FIG. 8) evaluates the parameters according to logic flow diagram 2900 (FIG. 29) and performs no operation. When the expression structure 2200 (FIG. 22) expresses the expression, that is, when a function call is expressed, (i) the field “num” Operands "2208 specifies the number of parameters of the called function as the number of operands, and (ii) field" operands "2210 is an array of expression structures, each element of which is an element of the called function An expression structure that represents a parameter.

  Each parameter is evaluated by evaluating each element of the field “operands” 2210. The array of items representing the parameters of the called function is organized in the loop formed by loop step 3348, step 3349, and NEXT step 3350, as will be described in detail later (in connection with FIG. 46). Used to emulate execution of the function called in step 3352.

  Once each parameter of the called function is evaluated, processing proceeds from loop step 3348 (FIG. 33E) to step 3351. In step 3351, the execution engine 802 (FIG. 8) extracts a function model structure that represents the effect of execution on the external of the called function. The function model structure has been previously described in connection with FIGS. From step 3351 (FIG. 33E), processing proceeds to step 3352, where the execution engine 802 (FIG. 8) emulates the execution of the called function, which will be described in detail later. Briefly described here, the function to be called emulates an operation specified in a function model structure such as the function model structure formed from the function models (3), (4), and (5) described above. Is done by applying The function model structure corresponding to the called function specifies an operation that expresses the effect of execution on the external of the called function. After completion of step 3352 (FIG. 33E), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

Substitution As noted above, if the expression operator is not a function call, processing proceeds from test step 3347 (FIG. 33E) to test step 3353. In the test step 3353, the execution engine 802 (FIG. 8) determines whether the operator of the function is an assignment operator or not, a field “kind” 2202 (FIG. 22) of the expression structure representing the expression. And the data specifying the assignment operator. In the C language, an assignment operator (ie, “=”) operates on two operands, ie, lhs and rhs, and moves the value of rhs to lhs. The substitution is evaluated for the item with the transferred value. For example, the expression “a = b” moves the value of the item “b” to the item “a” and is evaluated as an item having a new value of the item “a”.

  If the expression operator is not an assignment operator, processing ends according to logic flow diagram 2902 (FIGS. 33A-33E), ie, step 2902 (FIG. 29), and the expression processed according to logic flow diagram 2902 is Evaluates to a NULL value. The NULL value is used to indicate a state that does not have a valid value.

  If the execution engine 802 (FIG. 8) cannot properly evaluate an expression that lacks the subject function execution context in the computer process, the expression evaluates to a NULL value. The most important thing is not to properly evaluate the expression, but to track each external and resource state change. In order to ensure accurate tracking of this state, as many expressions are evaluated as possible.

  Conversely, in test step 3353 (FIG. 33E), if the expression operator is an assignment operator, processing proceeds to step 3353. In step 3353, the execution engine 802 (FIG. 8) evaluates the expression lhs as the expression itself according to the logic flow diagram 2900 (FIG. 29), and performs no operation. From step 3354 (FIG. 33E), processing proceeds to step 3355, where execution engine 802 (FIG. 8) evaluates rhs of the expression according to logic flow diagram 2900 (FIG. 29) and performs no operation. Processing proceeds from step 3355 (FIG. 33E) to step 3356, where the execution engine 802 (FIG. 8) generates the value of the item generated by the evaluation of the expression rhs by the evaluation of the expression lhs. Assign to an item. Step 3356 will be described in detail later in connection with logic flow diagram 3356 (FIG. 45). After step 3356 (FIG. 33E), processing ends according to logic flow diagram 2902, ie, step 2902 (FIG. 29).

  Accordingly, in step 2804 (FIG. 28), the execution engine 802 (FIG. 8) evaluates the expression according to the logic flow diagram 2900 (FIG. 29). In the expression evaluation, the execution engine 802 (FIG. 8) performs operations on the external and resource states as necessary, as described in detail above. As previously described, any state violation caused by the application of an operation in evaluating an expression is notified to the user as an error in the computer program 610.

Declaration Processing As described above, the declaration statement is processed in step 2808 (FIG. 28), which is shown in detail in logic flow diagram 2808 (FIG. 34). A declaration statement is represented by a statement structure such as a statement structure 1416 (FIG. 21) whose field “pointers” is an array of two pointers. As described above, the first pointer of the statement structure representing the declaration statement specifies a declaration structure such as the declaration structure 1506 (FIG. 16), and the second pointer defines the initial value of the declared item. Specifies an expression structure.

Processing according to logic flow diagram 2808 (FIG. 34) begins at step 3402, where an item structure, such as item structure 2700 (FIG. 27), is generated for the declared item. The A pointer that designates the generated item structure is stored in a field “item” 1608 (FIG. 16) of the declaration structure 1506. Field “type” “code” 2712 (FIG. 27) is set according to the type of data specified in the declaration, that is, according to the field “type” 1606 (FIG. 16) of the declaration structure 1506. The field “initialized” 2714 (FIG. 27). ) Is set to indicate that the item has not been initialized.

  Processing proceeds from step 3402 (FIG. 34) to test step 3404, where execution engine 802 (FIG. 8) determines whether the declaration statement specifies an initial value for the declared item, That is, it is determined whether the second pointer of the statement structure that represents the declaration statement specifies an expression structure or is a NULL value. If the declaration statement does not specify an initial value, that is, if the second pointer is NULL, processing ends according to logic flow diagram 2808 (FIG. 34). Conversely, if the declaration statement includes an expression that specifies an initial value, that is, if the second pointer specifies an expression statement, processing proceeds from test step 3404 to step 3406. In step 3406, execution engine 802 (FIG. 8) evaluates the expression represented by the expression structure according to logic flow diagram 2900 (FIG. 29), as described in detail above. When evaluating an expression according to logic flow diagram 2900, no operation is performed. Processing proceeds from step 3406 (FIG. 34) to step 3408, where the item whose expression is evaluated is assigned to the declared item. Furthermore, the field “initialized” 2714 (FIG. 27) of the item structure representing the declared item is set to indicate that the item has been initialized.

  After step 3408 (FIG. 34) ends, processing ends according to logic flow diagram 2808 and step 2808 (FIG. 28). Accordingly, in step 2808, a new item is generated, and if an initial value is specified, the new item is initialized to have the initial value.

Determination Process As described above, the execution engine 802 (FIG. 8) performs the determination process, that is, the process of the “if” statement in step 2812 (FIG. 28). Here step 2812 is shown in detail in logic flow diagram 2812 (FIG. 35). Processing begins at step 3502, where execution engine 802 (FIG. 8) evaluates an expression that is a predicate of an “if” statement according to logic flow diagram 2900 (FIG. 29) and applies operation p. . In the C language, the “if” statement includes a predicate and a second statement.

  This predicate is an expression that evaluates to a Boolean item that determines whether the second statement is executed. For example, the statement “if (a == b) ci1;” is a predicate, ie the expression “a == b”, evaluates to a Boolean item whose value is “true”, ie the item “a”. Specifies that the second statement, i.e. the statement "ci1", is executed only if is equal to the item "b". If item “a” is not equal to item “b”, statement “ci1” is not executed.

  Processing proceeds from step 3502 (FIG. 35) to test step 3504, where execution engine 802 (FIG. 8) determines whether the predicate has been evaluated for an item having a known value. The execution engine 802 makes this determination by comparing the item generated by the predicate evaluation with NULL. As described above, if the execution engine 802 cannot properly evaluate the expression, the expression is evaluated to NULL. If the predicate evaluates to an item having a known value, ie, a value other than NULL, processing proceeds from test step 3504 (FIG. 35) to test step 3506.

  In a test step 3506, the execution engine 802 (FIG. 8) compares the value of the item generated by the predicate evaluation with the Boolean value “true”. If the predicate evaluates to a Boolean item having a Boolean value of “true”, processing proceeds to step 3508 (FIG. 35), where execution engine 802 (FIG. 8) determines that the “if” statement Execute the second statement. The second statement is processed according to logic flow diagram 2800 (FIG. 28) as described in detail above. Accordingly, logic flow diagram 2800 is executed recursively.

  On the other hand, if the predicate evaluates to the Boolean value “false”, processing proceeds from test step 3506 (FIG. 28) to step 3510, where execution engine 802 (FIG. 8) controls the control record described in detail later. The data indicating the “else” condition is stored. The control record is used to provide an appropriate control flow in the emulation of subject function execution, as will be described in detail later. After either step 3508 (FIG. 35) or step 3510 ends, processing ends according to logic flow diagram 2812, ie, step 2812 (FIG. 28).

  As described above, the execution engine 802 (FIG. 8) determines in the test step 3504 (FIG. 35) whether or not the predicate has been evaluated to a known value. If the predicate does not evaluate to a known value, i.e., evaluates to NULL or evaluates to an item with an unknown value, processing proceeds from test step 3504 to step 3512. In step 3512, execution engine 802 (FIG. 8) simulates a Boolean value whose predicate can be evaluated. In one embodiment, the execution engine 812 (FIG. 8) randomly selects from the Boolean value “true” or the Boolean value “false”. From step 3512 (FIG. 35), processing proceeds to step 3514.

In step 3514, execution engine 802 (FIG. 8) makes as many guesses as possible from the Boolean value selected in step 3512 (FIG. 35). For example, if the predicate is the expression “a && b” (ie, a AND b) and the predicate is selected to have a Boolean value “true”, then the execution engine 802 (FIG. 8) will cause the items “a” and “ We assume that both b "have the Boolean value" true ". This guess can be made because the expression “a && b” evaluates to “true” only if both a and b are “true”. Step 3514 (FIG. 35) includes predicate processing according to logic flow diagram 3600 (FIG. 36). In each step of logic flow diagram 3600, the value in the expression is inferred from the estimated Boolean value estimated to be obtained by evaluating the expression.
“Not” operator
Processing according to logic flow diagram 3600 begins at test step 3602, in which execution engine 802 (FIG. 8) compares the computed value of the expression with the “NOt” operator, ie, the expression. Is compared with the field “kind” 2202 (FIG. 22) of the expression structure representing the “Not” operator. The “Not” operator (that is, “!”) Performs an operation on one operand, and generates an item having a logical negation of the value of the operand as the operation result. For example, the expression “! A” is the negation of the operand, ie, the expression “a”.

  If the expression operator is not a “Not” operator, processing proceeds from test step 3602 (FIG. 36) to test step 3606 described below. Conversely, if the expression operator is a “Not” operator, processing proceeds from test step 3602 to step 3606. In step 3606, execution engine 802 (FIG. 8) processes the operands according to logic flow diagram 3600 (FIG. 36) to infer a logical negation of the estimate. For example, when the expression “! (A && b)”, that is, NOT (a AND b) is estimated as “true”, the expression “a && b” is estimated as “false”. That is, the process according to the logic flow diagram 3600 is recursively executed. After completion of step 3604, processing ends according to logic flow diagram 3600.

“And” Operator or “Or” Operator As described above, when the operator of the expression is not the “Not” operator, the process proceeds from the test step 3602 (FIG. 36) to the test step 3606. In test step 3606, the execution engine 802 (FIG. 8) compares the operator of the expression with the “And” and “Or” operators. In other words, the execution engine 802 compares the field “kind” 2202 (FIG. 22) of the expression structure representing the expression with data specifying the “And” operator and the “Or” operator. As described above, the “And” operator and the “Or” operator (ie, “&&” and “||”) operate on two operands, ie, lhs and rhs, and the values of the two operands are obtained as the result of the operation. An item having the logical product and logical sum of the values as the values is generated. If the operator of the expression is neither the “And” operator nor the “Or” operator, the process proceeds from the test step 3606 (FIG. 36) to a test step 3610 described later. Conversely, if the operator of the expression is either the “And” operator or the “Or” operator, the process proceeds from the test step 3606 to step 3608.

  Step 3608 is shown in detail in a logic flow diagram 3608 (FIG. 37) where processing begins at test step 3702. In test step 3702, execution engine 802 (FIG. 8) compares the operator of the expression with the “And” operator and further estimates a Boolean value, ie, an estimate, when the expression is evaluated. Compare the value with the Boolean value “true”. If the operator is not an “And” operator, or if the estimated value is not “true”, the process proceeds from test step 3702 to test step 3706 described later. Conversely, when the operator is an “And” operator and when the estimated value is “true”, the process proceeds from test step 3702 to step 3704.

  In step 3704, each operand, ie, each of the expressions lhs and rhs, is processed as an expression with an estimate “true” according to logic flow diagram 3600 (FIG. 36). Such an assumption that both lhs and rhs are “true” is appropriate. This is because if the expression “a && b” is “true”, both operands, ie, the expressions “a” and “b” must both be “true”. As described above, the C language operator “&&” means a logical product operation. After completion of step 3704 (FIG. 37), processing ends according to logic flow diagram 3608, ie, step 3608 (FIG. 36).

  As described above, when the operator is not the “And” operator or the estimated value is not “true”, the process proceeds from the test step 3702 (FIG. 37) to the test step 3706. In a test step 3706, the execution engine 802 (FIG. 8) compares the operator of the expression with the “Or” operator, and compares the estimated value with the Boolean value “false”. If the expression operator is not the “Or” operator or the estimated value is not “false”, processing ends according to logic flow diagram 3608, ie, step 3608 (FIG. 36). Conversely, when the operator is the “Or” operator and the estimated value is “false”, the process proceeds from the test step 3706 (FIG. 37) to step 3708.

In step 3708, each of the operands, i.e., lhs and rhs of the expression, is processed as an expression with an estimate "false" according to logic flow diagram 3600 (Figure 36). Such an assumption that lhs and rhs are “false” is appropriate. This is because if the expression “a || b” is “false”, both operands, ie, “a” and “b” must both be “false”. As described above, the C language operator “||” means a logical sum operation. After step 3708 (FIG. 37) ends, processing ends according to logic flow diagram 3608, ie, step 3608 (FIG. 36).
After step 3608 ends, processing ends according to logic flow diagram 3600.

Relational Operator As noted above, if the expression operator is neither the “And” operator nor the “Or” operator, processing proceeds from test step 3606 to test step 3610. In test step 3610, execution engine 802 (FIG. 8) compares the expression operator with the following relational operators. The relational operators are smaller (“<”), smaller or equal (“<=”), larger (“>”), greater than or equal (“> =”), equal ( “==”) and inequality (“! =”). More specifically, the execution engine 802 compares the field “kind” 2202 (FIG. 22) of the expression structure representing the expression with data specifying each of these relational operators. As described above, the relational operator performs an operation on two operands, that is, lhs and rhs of an expression, and generates a Boolean item having a value corresponding to the relationship between lhs and rhs as an operation result. If the expression operator is not a relational operator, processing proceeds from test step 3610 (FIG. 36) to test step 3614 described below. Conversely, if the expression operator is a relational operator, processing proceeds from test step 3610 to step 3612.

In step 3612, the execution engine 802 (FIG. 8) evaluates the relational operator. Step 3612 (FIG. 36) is detailed in a logic flow diagram 3612 (FIG. 38) where processing begins at step 3802. In step 3802, execution engine 802 (FIG. 8) determines whether both lhs and rhs are known, i.e., evaluates to an item having a known value, and both lhs and rhs. Is unknown, that is, whether it evaluates to an item having an unknown value. If the item represented by the item structure 2700 (FIG. 27) has an unknown value, the field “type” code "2712 indicates that the type of the item is unknown. If both lhs and rhs of the expression are known or both are unknown, then according to logic flow diagram 3612 (FIG. 38), step The processing ends according to 3612 (FIG. 36), because there is nothing to be inferred when both operands are known, and there is nothing that can be inferred when both operands are unknown. Conversely, if one of the operands is known and the other is unknown, processing proceeds from test step 3802 (FIG. 38) to test step 3804.

  In test step 3804, execution engine 802 (FIG. 8) determines whether any operand is undefined. If an operand does not evaluate to an item represented by the item structure, that is, if the operand evaluates to a NULL value, the operand is undefined. In such a case, there is no item to which the estimated value should be substituted. Thus, if one operand is undefined, processing ends according to logic flow diagram 3612 (FIG. 38), ie, step 3612 (FIG. 36). Conversely, if both operands are defined, the process proceeds from test step 3804 (FIG. 38) to test step 3806.

In test step 3806, the execution engine 802 (FIG. 8) performs an expression operator, an “=” operator, and a “not” The "equal" operator is compared and the estimated value is compared with the Boolean values "true" and "false." (i) The operator of the expression is the "=" operator and the estimated value is "true" And (ii) the operator of the expression is “not” If the condition “equal” operator and the condition that the estimated value is “false” are not satisfied, the process proceeds from test step 3806 (FIG. 38) to test step 3814 described later. (I) the condition that the operator of the expression is the “=” operator and the estimated value is “true”, and (ii) the operator of the expression is “not” If it is an “equal” operator and one of the conditions that the estimated value is “false” is satisfied, the process proceeds from test step 3806 to test step 3808.

In test step 3808, one operand is a known value and the other operand has an unknown value. An operand whose value is known evaluates to “known item”. An operand whose value is unknown evaluates to “unknown item”. Further, in test step 3808, it is estimated that the two operands have equal values. In test step 3808, execution engine 802 (FIG. 8) determines whether the known item has a NULL value. (I) The item type is the field “type”. code ", that is, the field" type "of the item structure 2700 As specified in code “2712” (FIG. 27), the condition indicating that it is either “long” or “pointer”, and (ii) the value of the item in the field “value” That is, as specified in the field “value” 2706 of the item structure 2700, if both of the conditions indicating zero are satisfied, the item has a NULL value.

  If the known item has a NULL value, processing proceeds from test step 3808 (FIG. 38) to step 3810, where an operation x is applied to mark the resource associated with the lesser known item as invalid. Is made. The resource is invalid because the value of the unknown item with which the resource is associated is presumed to be equal to a known item whose value is NULL, ie the pointer to the resource is presumed NULL It is.

  Processing proceeds from step 3810 to step 3812. Further, if the known item does not have a NULL value, processing proceeds directly from test step 3808 to step 3812. In step 3812, the value of the known item is substituted into the unknown value in the manner described in detail below. Therefore, the value of the known item is inferred from the value of the known item if it is estimated that the known item and the unknown item are equal. After step 3812 ends, processing ends according to logic flow diagram 3612, ie, step 3612 (FIG. 36).

  As described above, the condition that the operator of the expression (i) is the “=” operator and the estimated value is “true”, and the operator of the expression (ii) is “not”. If both the “equal” operator and the condition that the estimated value is “false” are not satisfied, the process proceeds from the test step 3806 (FIG. 38) to the test step 3814. In the test step 3814, the process is executed. The engine 802 (FIG. 8) determines that the operator of the expression (i) is “not” "equal" operator and whether or not the condition that the estimated value is "true" is satisfied, or (ii) the condition that the operator of the expression is the "=" operator and the estimated value is "false" If neither condition (i) nor condition (ii) is satisfied, the process ends according to the logic flow chart 3612, that is, according to step 3612 (FIG. 36). If not, that is, if either condition (i) or condition (ii) is met, processing proceeds from test step 3814 (FIG. 38) to test step 3816.

  In test step 3816, execution engine 802 (FIG. 8) infers that the two operands, ie, lhs and rhs are not equal to each other. If the known item has a NULL value, it is assumed that the unknown item has a non-NULL value. In the context of various implementations of the C language, NULL is the value zero. Thus, it is assumed that the unknown item has a non-zero value. In a test step 3816 (FIG. 38), the execution engine 802 (FIG. 8) compares the value of a known item with NULL. If the value of the known item is not NULL, processing ends according to logic flow diagram 3612 (FIG. 38). Conversely, if the value of the known item is NULL, the process proceeds to test step 3818.

  In test step 3818, execution engine 802 (FIG. 8) determines whether a resource in state Q is associated with a known item. As described above, a resource is in state Q if it is unknown whether the resource is in an assigned state, an unassigned state, or an invalid state. If the unknown item is associated with a resource in state Q, processing proceeds to step 3820 (FIG. 38), where operation a is performed on the resource associated with the unknown item. The Since it is presumed that the item to which the resource is associated is not equal to NULL, the operation a is performed in order to keep the resource clearly assigned. From step 3820, processing proceeds to step 3822. Further, if the unknown item is not associated with a resource in state Q, processing proceeds directly from test step 3818 to step 3822.

In step 3822, the field “type” of the item structure representing the unknown item. “code” 2712 (FIG. 27) is set to indicate that the item is non-zero, and the field “invalid” of the item structure representing the unknown item. Pointer "2720 is set to indicate that the unknown item has no invalid pointer, i.e., a NULL value. After the end of step 3822, processing ends according to logic flow diagram 3612.

  Thus, according to logic flow diagram 3612, ie, according to step 3612 (FIG. 36), when one of the operands of the expression is known and the other operand is not known and both operands are assumed to be equal or not equal. When it is estimated, a guess is made. The guess is made for both the value of both operands of the expression and the state of the resource associated with the operand of the expression. After step 3612 ends, processing ends according to logic flow diagram 3600.

Compound Operator As noted above, if the expression operator is not a relational operator, processing proceeds from test step 3610 to test step 3614. In test step 3614, execution engine 802 (FIG. 8) compares the operator of the expression with the compound operator (“,”). In other words, the execution engine 802 compares the field “kind” 2202 (FIG. 22) of the expression structure that expresses the expression with the data specifying the compound operator. The compound operator operates on two operands: lhs and rhs. Here both lhs and rhs are evaluated, and the expression evaluates to rhs. For example, in the evaluation of the expression “a, b”, both the operand “a” and the operand “b” are evaluated, and then the expression “a, b” is evaluated as “b”.

  If the operator is a compound operator, processing proceeds to step 3616 (FIG. 36), where execution engine 802 (FIG. 8) performs processing according to logic flow diagram 3600 (FIG. 36) to provide an estimate. Gives a Boolean value that is estimated to evaluate the expression. The value of rhs is inferred from the estimated value of the expression because the expression evaluates to rhs. For example, if the expression “a == b, c == d” is estimated to be true, then rhS, that is, the expression “c == d” is estimated to be true. Accordingly, processing is performed recursively on the rhs of the expression according to logic flow diagram 3600 and at step 3616, according to logic flow diagram 3600. After step 3616 ends, processing ends according to logic flow diagram 3600. If the operator is not a compound operator, processing ends according to logic flow diagram 3600 and step 3616 is skipped.

  Thus, as described above, as long as execution engine 802 (FIG. 8) can execute in step 3514 (FIG. 35) by recursively processing expressions and subexpressions according to logic flow diagram 3600, Estimate the items related to the formula item and the formula item from the estimated value of the formula. Processing proceeds from step 3514 to test step 3506 described above.

  Accordingly, in step 2812 (FIG. 28), the execution engine 802 (FIG. 8) performs the decision process in the “if” statement according to the logic flowchart 3812.

Return Processing As described above, the “return” statement is processed in step 2816. The “return” statement ends the execution of the function, and assigns a value to the return value item of the function if a return value item is defined. Step 2816 is shown in detail in a logic flow diagram 2816 (FIG. 39) where processing begins at step 3902.

  In step 3902, the execution engine 802 (FIG. 8) determines whether or not the “return” statement specifies a return value item. The “return” statement specifies a return value item if it contains an expression. For example, if the statement structure 1416 (FIG. 21) represents a “return” statement, the field “pointers” 2110 is either a pointer that specifies an expression structure, or is NULL. If the “return” statement specifies a return value item, ie, the field “pointers” 2110 specifies an expression structure, processing proceeds from test step 3902 (FIG. 39) to step 3904, where “return” "The expression of the statement is evaluated according to the logic flow diagram 2900 (Figure 29) and no operation is performed. In step 3904 (FIG. 39), no operation is performed in evaluating the expression of the “return” statement, but as previously described in connection with steps 3306, 3307, and 3314 (FIG. 33A-B), It is also possible to perform some operation on the operand. From step 3904 (FIG. 39), the process proceeds to step 3906, where the items generated by the execution engine 802 (FIG. 8) evaluating the expression in step 3904 (FIG. 39) are changed to the subject function. Assign to the item structure that represents the return value item. Substituting the value of one item into another item will be described in detail later.

  Processing proceeds from step 3906 to step 3908. If the “return” statement does not specify a return value item, the process proceeds directly from step 3902 to step 3908. In step 3908, the execution engine 802 (FIG. 8) provides data indicating a “return” condition used to provide a control flow through the subject function during emulation of the execution of the subject function, as will be described in detail later. Is stored in the control record. After step 3908 (FIG. 39), processing ends according to logic flow diagram 2816, ie, step 2816 (FIG. 28).

Block processing In many functions, a block of statements defines the behavior of the function. In the context of the C language, a block of statements is enclosed between an opening parenthesis, “{”, and an closing parenthesis, “}”, which is itself a block statement. In a function defined in the C language, a first block of statements generally includes a second block of statements. For example, the source code excerpt (1) includes the second block of statements from the 16th line to the 21st line in the first block of statements from the 9th line to the 32nd line. At this time, the first block of the statement is a superblock of the second block of the statement, and the second block of the statement is a sub-block of the first block of the statement.

  (P118b) As described above, the block statement structure includes a pointer that points to the statement structure, ie, the statement structure 1416 (FIG. 21) representing the first statement of the block. The statement structure 1416 includes a field “next” 2106 used to maintain a single-linked list of statement structures representing each statement in the block, as described above. As described above, the block statement is processed in step 2820 (FIG. 28), the details of which are shown in the logic flow diagram 2820 (FIG. 40), and the logic flow diagram shows the block statement. Describes the processing of statement structures in a block of statements for emulation of execution.

  In step 4002, the execution engine 802 (FIG. 8) retrieves a statement structure that represents the first statement of the block. As described above, the statement structure that represents the first statement of the block is specified by the block statement structure. The retrieved statement structure is the current statement structure. Processing proceeds from step 4002 (FIG. 40) to test step 4004.

  In test step 4004, execution engine 802 (FIG. 8) determines whether the current statement structure represents an “else” statement and the control record indicates an “else” condition. In the C language, the “else” statement is well known and is described in section 6.6.4.1 of the C standard. A statement structure such as statement structure 1416 (FIG. 21) represents an “else” statement when field “kind” 2102 is indicated as such. Control records are maintained within the execution engine 802 (FIG. 8) to manage the flow of control during emulation of subject function execution. As described above in connection with step 3510 (FIG. 35), the control record is set to indicate an “else” condition when processing the “if” statement, and the predicate of the “if” statement is a Boolean “ It is evaluated as “false”. If the current statement structure does not represent an “else” statement or the control record does not indicate an “else” condition, processing proceeds from test step 4004 (FIG. 40) to step 4006, where Execution of the statement represented by the current statement structure is emulated according to logic flow diagram 2800 (FIG. 28) as described above. Conversely, if the current statement structure represents an “else” statement and the control record does not indicate an “else” condition, processing proceeds from test step 4004 (FIG. 40) to step 4014 described below. Proceeding, step 4006 is bypassed.

  As described above, a block of statements can include sub-blocks. Also, as described above, at step 4006, the current statement structure is processed according to logic flow diagram 2800 (FIG. 28). Thus, execution of the block statement in step 4006 (FIG. 40) causes step 2820 (FIG. 28) to be recursively executed, thus each step of the logic flow diagram 2820 (FIG. 40) is recursively executed, Emulation of sub-block execution is performed. Once the sub-block statement has been processed according to the logic flow diagram 2820, the processing of the block statement at step 4006 is complete and processing according to the sub-block statement logic flow diagram 2820 continues. Processing proceeds from step 4006 to test step 4008.

  In test step 4008, execution engine 802 (FIG. 8) performs control records set by emulation of statement execution as described above in connection with logic flow diagram 2800 (FIG. 28), and a “return” condition; Comparison is made with data indicating the “exit” condition or the “long jump” condition. As described above in connection with step 3908 (FIG. 39), in step 4006 (FIG. 40), upon emulation of execution of the “return” statement, the control record is set to indicate a “return” condition. The “exit” condition occurs when the execution engine 802 (FIG. 8) processes a call to the library function exit (). This library function exit () is described in section 7.10.4.3 of the C standard. The “long jump” condition occurs when the execution engine 802 processes a call to the library function longjmp (). This library function longjmp () is also described in section 7.6.2.1 of the C standard. If the control record indicates a “return” condition, an “exit” condition, or a “long jump” condition, processing ends according to logic flow diagram 2820 (FIG. 40). Conversely, if the control record does not indicate any of the “return” condition, the “exit” condition, or the “long jump” condition, the process proceeds from the test step 4008 to the test step 4010.

  In a test step 4010, the execution engine 802 (FIG. 8) compares the control record with data indicating a “break” condition or a “continue” condition. In step 4006, the control record is set to indicate a “break” condition or a “continue” condition during emulation of execution of a “break” statement or a “continue” statement. If the control record is set to indicate either a “break” condition or a “continue” condition, the process proceeds to step 4010, where the control record is set to indicate a “next” condition, Finish according to logic flow diagram 2820.

  The “next” condition is a general processing condition when the execution of the “next” statement of the block is emulated. Thus, if the current block of statements executes a “break” statement, processing of the current block ends and processing proceeds to the statement immediately following the current block in the superblock of the current block. In contrast, the “return” condition does not reset the control record. Therefore, the emulation of the execution of the “return” statement in step 4006 ends the processing of the current block through the above-described test step 4008, and similarly ends the processing of any super block of the current block.

  On the other hand, if the control record indicates neither a “break” condition nor a “continue” condition, the process proceeds from test step 4010 to step 4014. Further, if the current statement structure represents an “else” statement and the control record does not indicate an “else” condition as described above, processing proceeds from test step 4004 to 4014. In step 4014, the execution engine 802 (FIG. 8) retrieves the field “next” 2106 (FIG. 21) of the current statement structure, makes the retrieved statement structure the current statement structure, and the previous current structure. Replace the statement structure.

  Processing proceeds from step 4014 (FIG. 40) to test step 4016, where execution engine 802 (FIG. 8) compares the pointer specifying the current statement structure with NULL. If the pointer specifying the current statement structure is NULL, the final statement of the block of statements is processed according to logic flow diagram 2820 (FIG. 40) and processing ends according to logic flow diagram 2820. Conversely, if the pointer specifying the current statement structure is not NULL, processing proceeds from test step 4016 to test step 4004 described above.

  Accordingly, execution of the block of statements is emulated and the flow of control in the block of statements flows as shown in logic flow diagram 2820 (FIG. 40).

Leak Processing As described above, once execution of a subject function statement is emulated, a leak is detected in step 2606 (FIG. 26). Details of step 2606 are shown in logic flow diagram 2606 (FIG. 41). Processing begins at loop step 4102 according to logic flow diagram 2606. Loop step 4102 and NEXT step 4106 form a loop in which each external of the subject function is processed according to step 4104. In step 4104, the execution engine 802 (FIG. 8) marks all resources reachable by the external (mark). If the resource is associated with any item in the external or a bunch that includes the external, the resource is a resource that the external can reach. The crowd will be described in detail below. Using the illustrative example, a resource associated with an array element that is a cluster type is reachable from any element of the array.

  The resource, ie the resource represented by the resource state structure 3100 (FIG. 31), is marked by setting the field “mark” 3114 of the resource state structure 3100 to indicate it. Once each resource reachable by each external is marked in the loop formed by loop step 4102 (FIG. 41) and NEXT step 4106, processing proceeds from loop step 4106 to loop step 4108.

  Loop step 4108 and NEXT step 4114 form a loop in which each resource is processed. Resource state structures are maintained in a single linked list to facilitate processing of all resource state structures. For example, the resource state structure 3100 (FIG. 31) includes a field “next” 3112 that specifies the next resource state structure in the single linked list. For each resource represented by a resource state structure in memory 104 (FIG. 1), processing proceeds from loop step 4108 (FIG. 41) to test step 4110.

  In the test step 4110, it is determined whether or not the execution engine 802 (FIG. 8) is assigned a resource, that is, whether it is in the state A or the state Q, and not marked. Resources that are assigned and not marked, that is, resources that are not reachable from any external, are leaking. If the resource has been allocated and not marked, processing proceeds from test step 4110 (FIG. 41) to step 4112 where the leak is notified to the user. If the resource is not allocated, ie not in state A or state Q or marked, processing proceeds directly from test step 4110 to NEXT step 4114.

  Further, processing proceeds from step 4112 to NEXT step 4114. Processing proceeds from NEXT step 4114 to loop step 4108 where the next resource is processed as described above and finally all resources are processed. Once each resource is processed in the loop formed by loop step 4108 and NEXT step 4114, processing ends according to logic flow diagram 2606, ie, step 2606 (FIG. 26).

  Thus, a leak is detected and notified according to logic flow diagram 2606, ie according to step 2606 (FIG. 26).

External Construction As described above, in step 2608, each external is constructed according to a logic flow diagram 4200 (FIG. 42). Processing according to logic flow diagram 4200 begins at test step 4202, in which execution engine 802 (FIG. 8) determines whether a resource is associated with the external. A determination as to whether or not a resource is associated with an external represented by the external list structure 1414 (FIG. 15) will be described below using an example for explanation. Field "first" Decl "1502 specifies a declaration structure 1506, which includes a field" item "1608. The field" item "1608 specifies an item structure, that is, an item structure 2700. The field" item structure 2700 ". When resource "2702 (FIG. 27) designates a resource state structure, the resource is associated with the external represented by the external list structure 1414 (FIG. 15). If it is associated with the resource represented by resource state structure 3100 (FIG. 31), processing proceeds from test step 4202 (FIG. 42) to step 4204, where field “state” 3102 (FIG. 31). The process is a step Proceeds to step 4210 to be described later from 204.

  If there are no resources associated with the external, processing proceeds from test step 4202 to test step 4206. In test step 4206, execution engine 802 (FIG. 8) determines whether the external is an invalid pointer. The type of the external is the field “type” of the item structure that represents the item associated with that external. code "2712 (Fig. 27), which is VALUE TYPE NON If it is ZERO, the external is an invalid pointer. Type VALUE TYPE NON ZERO indicates that the item has a non-zero value. A field “invalid” of the item structure representing the item associated with the external pointer ", ie the field" invalid " If pointer "2720" indicates that, or if the value of the external is 0 or -1, the external is an invalid pointer.

  If the external is an invalid pointer, processing proceeds from test step 4204 (FIG. 42) to step 4208 where the state of the resource of the external is set to state X. For example, if the resource represented by the resource state structure 3100 (FIG. 31) is associated with the external represented by the external state structure 3000 (FIG. 30), the data indicating the state X is the field. It is stored in “state” 3102 (FIG. 31). From step 4208 (FIG. 42), processing proceeds to step 4210. Further, processing proceeds from step 4204 as described above, or from test step 4206 to step 4210 if the external is not an invalid pointer.

  In step 4210, the external composite RS, DK and CP states are updated. The configuration of the state was previously described in detail with respect to FIGS. 3B, 4B, and 5B. After step 4210, processing ends according to logic flow diagram 4200.

Function Output Model As described above, the model machine 808 (FIG. 8) generates and stores a model of the subject function in step 2412 (FIG. 24). Step 2412 is detailed in logic flow diagram 2412 (FIG. 43). The process starts from step 4302, where the model machine 808 (FIG. 8) assigns and initializes a function model structure such as the function model structure 1100 (FIG. 11). The functional model structure 1100 includes, in one embodiment, a field “name” 1102, a field “description” 1108, a field “file” 1110, a field “line” 1112, and a field “automated” 1106 (i) its behavior. Is the identifier of the function modeled in the function model structure 1100, (ii) a textual description of the function, (iii) the name of the source code file, (iv) in the source code file in which the function is defined And (v) a Boolean value indicating that the function has been automatically modeled, respectively. If the model of the function is generated by the model machine 808 (FIG. 8), the function is automatically modeled. Conversely, if a model of the function is generated by a user using a text editor (not shown) in computer 100 (FIG. 1), the function is modeled manually. For example, the library functions fopen (), malloc (), and free () are modeled manually. The function model structure field “automated” 1116 (FIG. 11) is called from the model description file 604 (FIG. 6) in step 904 (FIG. 9) as described above. Is set to indicate that it is modeled.

  From step 4306 (FIG. 43), processing proceeds to step 4304, where an external model structure, such as external model structure 1200 (FIG. 12), is generated for and corresponding to each external of the subject function. It is inserted into the single linked list of the external model structure in the function model structure. For example, the field “first external” 1104 (FIG. 11) and the field “last external” 1106 are used to associate the function model structure 1100 with a single linked list of external model structures, as described above. One external process is performed according to step 4304 (FIG. 43), which is illustrated in logic flow diagram 4400 (FIG. 44).

  Processing begins at step 4402 according to logic flow diagram 4400, where model machine 808 (FIG. 8) is an external type, ie, the external is a parameter, a return value item, or an item (ie, Globally defined items or static items). If the external is a parameter, the model machine 808 (FIG. 8) determines the position of the parameter in the subject function definition. The first parameter is parameter number zero, and the final parameter number is one less than the parameter number defined for the subject function. If the external is an item, the model machine 808 (FIG. 8) determines the identifier of the item. The external type is stored in the field “type” 1204 of the external model structure 1200 (FIG. 12) as described above. Similarly, when a parameter number is obtained, the parameter number is stored in a field “parameter number” 1206, and when an item is obtained, an identifier of the item is stored in a field “name” 1208. .

  Processing proceeds from step 4402 to step 4404 where the model machine 808 (FIG. 8) determines the number of operations and determines the particular operation to be performed externally during emulation of subject function execution. In step 4404, the number of operations and the number of operations to be performed are determined according to the external composite DK state. Table N below outlines the operations and number of operations derived from the external composite DK state.

  Therefore, for example, when the external composite DK state is the state A, the operation a is performed on the external in the emulation of the execution of the subject function. Also, when the external composite DK state is the state KQ, in the emulation of the execution of the subject function, the operation k and then the operation m are performed on the external. As noted above, the external composite state identifies the global effect of multiple emulation of subject function execution. Thus, operations derived from the composite state of the external represent the essence of the cumulative effect of executing the subject function on that external.

  Processing proceeds from step 4404 to test step 4406, where model machine 808 (FIG. 8) compares the number of operations performed on that external with zero. If the number of operations performed on that external is equal to zero, processing proceeds to step 4408 (FIG. 44) where the model machine 808 (FIG. 8) determines the number of operations and the external's A specific operation to be performed on the external at the time of emulation of the subject function according to the composite CP state is obtained. Table O below outlines the operations and number of operations derived from the external composite CP state.

Thus, if the external composite DK state does not provide enough information on the cumulative effect of subject routine execution on the external, the external composite CP state is the cumulative effect of subject function execution. Is used to determine Using an example for explanation, when the composite CP state of the external is the state i, the operation i is performed on the external by emulation of the subject function. In either step 4404 (FIG. 44) or step 4408, the operations and number of operations performed on the external are the fields “operations” 1214 (FIG. 12) and “number” of the external model structure 120. of The process proceeds from step 4408 (FIG. 44) to step 4410. Further, the model machine 808 (FIG. 8) determines in step 4404 in the test step 4406 (FIG. 44). If it is determined that the number of operations performed on that external is zero, as is done, processing proceeds directly from test step 4406 to step 4410.

In step 4410, the model machine 808 (FIG. 8) determines the initial state of the resource associated with the external from the external composite RS state. That is, the external composite RS state is the field “initial” of the external model structure 1200. stored in state "1220 (FIG. 12). The composite RS state of the external reflects the cumulative effect of subject function execution on the resource associated with that external. Processing is tested from step 4410 (FIG. 44). Proceeding to step 4412, where the model machine 808 (FIG. 8) compares the external composite RS state with the state NONE indicating that there are no resources associated with the external, associated with the external. If the resource does not exist, processing proceeds from test step 4412 (FIG. 44) to step 4414 where the Boolean value “false” is the field “new” of the external model structure 1200. resource "1218 (FIG. 12). Conversely, if the resource is associated with the external, that is, if the external composite RS state is other than NONE, processing proceeds to test step 4412 (FIG. 12). 44) proceeds to step 4416. In step 4416, the model machine 808 (FIG. 8) moves the field “new” of the external model structure 1200. A Boolean value “true” is stored in resource “1218” (FIG. 12) to indicate that a new resource associated with the external is generated by subject function emulation.

  Processing proceeds from either step 4414 (FIG. 44) or step 4416 to step 4418, where model machine 808 (FIG. 8) replaces external model structure 1200 (FIG. 12) with function model structure 1100 (FIG. 12). Inserted into the single linked list of the external model structure of FIG. After the end of step 4418 (FIG. 44), processing ends according to logic flow diagram 4400.

  After each external of the subject function has been processed in step 4304 (FIG. 43) according to logic flow diagram 4400, processing proceeds to step 4306 where a function model structure 1100 (FIG. 11) representing the subject function is all Are stored in a data structure including a function model structure. After step 4306, processing ends according to logic flow diagram 2412, ie, step 2412 (FIG. 24). The function model represented by the stored function model structure is then used to emulate execution of the subject function when analyzing other functions that make calls to the subject function, as will be described in detail later. Can be used.

Substitution of the value of one item into another item As described above, in step 3356 (FIG. 33C), the value of one item, ie, rhs, is assigned to the other item, ie, lhs. Step 3356 is shown in detail in logic flow diagram 3356 (FIG. 45), where processing begins at test step 4502. In test step 4502, execution engine 802 (FIG. 8) determines whether lhs and rhs are represented by items. As described above, an expression such as lhs or rhs is evaluated as one item if the execution engine 802 has sufficient information to evaluate the expression, and is set to a NULL value in other cases. Be evaluated. If an expression evaluates to an item, the expression is represented by that item. If either lhs or rhs is not represented by one item, the process proceeds from test step 4502 (FIG. 45) to test step 4510 described below. Conversely, if both lhs and rhs are represented by one item, processing proceeds from test step 4502 to step 4504.

In step 4504, an item representing lhs, ie, a field of the lhs item is formed equal to a corresponding item representing rhs, ie, the rhs item. More specifically, the item structure 2700 field “resource” 2702 (FIG. 27), “external” 2704, “value” 2706, “type” code "2712," initialized "2714, and" invalid " Data is stored in the field of the rhs item corresponding to each of the pointer "2720. The processing proceeds from step 4504 (FIG. 45) to the test step 450, where the execution engine 802 (FIG. 8) has the rhs initial value. The execution engine 802 compares the field of the rhs item corresponding to the field “initialized” 2714 (FIG. 27) of the item structure 270 with the Boolean value “false”. Make such a determination.

  If rhs is initialized, that is, if the field of the rhs item corresponding to the field “initialized” 2714 (FIG. 27) of the item structure 2700 has a Boolean value “true”, the process is as follows. The process ends according to logic flow diagram 3356, ie, step 3356 (FIG. 33E). Conversely, when rhs is not initialized, that is, when the field of the rhs item corresponding to the field “initialized” 2714 (FIG. 27) of the item structure 2700 has a Boolean value “false”, Processing proceeds from test step 4506 (FIG. 45) to step 4508. In step 4508, an error message is sent to the error log file and / or display on video monitor 118 as described above to warn that uninitialized data is being used. Since the field of the rhs item corresponding to the field “initialized” 2714 (FIG. 27) is copied to the corresponding field of the lhs item in step 4504 as described above, the lhs item is not initialized. A mark is made. After step 4508 (FIG. 45) is complete, processing is terminated according to logic flow diagram 3356, ie, step 3356 (FIG. 33C).

  As described above, if either lhs or rhs is not represented by an item, the process proceeds from test step 4502 (FIG. 45) to test step 4510. In test step 4510, execution engine 802 (FIG. 8) determines whether rhs and lhs are individually represented by items. If lhs is represented by an item and rhs is not represented by an item, processing proceeds from test step 4510 (FIG. 45) to step 4512. Otherwise, processing ends according to logic flow diagram 3356, ie, step 3356 (FIG. 33E).

In step 4512 (FIG. 45), the execution engine 802 (FIG. 8) marks the lhs item as unknown. For example, if the item structure 2700 (FIG. 27) represents an lhs item, the execution engine 802 (FIG. 8) (i) stores data indicating the type of unknown data in the field “type”. code ”2712 (FIG. 27), (ii) data indicating that the lhs item is not initialized is stored in the field“ initialized ”2714, and (iii) lhs is not associated with an external or resource To indicate that lhs is not known by storing NULL in the fields “resource” 2702 and “external” 2704. After step 4512 (FIG. 45), processing proceeds according to logic flow diagram 3356. That is, the process ends according to step 3356 (FIG. 33E).

  Accordingly, in step 3356, the value of the item representing rhs is substituted for the item representing lhs. As described above, the execution engine 802 (FIG. 8) substitutes the value of the item obtained by evaluating the expression in step 3408 (FIG. 34) into the declared item. This substitution in step 3408 is similar to the substitution of the rhs item into the lhs item described above in connection with logic flow diagram 3356 (FIG. 45). As described above with respect to step 3812 (FIG. 38), execution engine 802 (FIG. 8) substitutes the value of a known item into an unknown item. The substitution of a known item into an unknown item in step 3812 (FIG. 38) is similar to the substitution of the rhs item into the lhs item described above in connection with logic flow diagram 3356. As described above, the execution engine 802 (FIG. 8) substitutes the value of the item obtained by evaluating the expression in the return value item in step 3906 (FIG. 39). This substitution process in step 3906 is similar to the substitution of the rhs item into the lhs item described above in connection with logic flow diagram 3356 (FIG. 45).

Function Emulation As described above, the execution engine 802 (FIG. 8) evaluates function calls by emulating function execution in step 3352 (FIG. 33E). Step 3352 is detailed in logic flow diagram 3352 (FIG. 46), where processing begins at step 4602. Execution of a function call is emulated according to a function model structure that represents the behavior of the called function. In a test step 4602, the execution engine 802 (FIG. 8) determines whether or not a function model structure representing the behavior of the called function is stored in the memory 104 (FIG. 1). As described above, the function model structure 1100 (FIG. 11) has the field “name” 1102 that includes data representing the identifier of the function whose behavior is represented by the function model structure 1100. The corresponding fields of the various function model structures that represent the behavior of each function are compared with the identifiers used by the subject function to call the function, until this is done until all function model structures have been checked. Or until a function model structure whose field “name” matches the identifier is found.

  If a function model structure with field “name” matching the identifier is not found, processing proceeds from test step 4602 (FIG. 46) to step 4604, where the emulation of the execution of the called function is evaluated. NULL is generated as an item obtained by this. As described above, when the execution engine 802 (FIG. 8) does not have enough information to properly evaluate the expression, the expression evaluates to NULL. After execution of step 4604 (FIG. 46), processing ends according to logic flow diagram 3352, ie, step 3352 (FIG. 33E).

On the other hand, when a function model structure whose field “name” matches the identifier used by the subject function for calling the function, that is, a function model structure expressing the behavior of the called function is found, processing is performed. Advances from test step 4602 (FIG. 46) to loop step 4606. Loop step 4606 and NEXT step 4630 form a loop, and each external represented by the external model structure in the function model structure of the function called in this loop is processed. As previously described in connection with FIG. 13, a function model structure, such as function model structure 1100A, is a field “first” that specifies the first external model structure in the single linked list of external model structures. external "1104A is included. For each external in the single linked list of the external model structure of the function model structure of the called function, processing proceeds from loop step 4606 (FIG. 46) to test step 4608. After each external of the single model linked list of the external model structure of the function model structure of the function is processed, processing proceeds from loop step 4606 to step 4632, described in detail below.

  In the context of the description of steps 4608-4628 below, the external model structure processed according to the loop formed by loop step 4606 and NEXT step 4630 includes, as an example to illustrate the processing of the external model structure: Assume that the external model structure 1200 (FIG. 12) is used. In a test step 4608 (FIG. 46), the execution engine 802 (FIG. 8) indicates whether the external model structure 1200 (FIG. 12) represents a parameter, a field “type” 1204 and the parameter. Judgment is made by comparing the data. If the external model structure 1200 does not represent a parameter, processing proceeds from test step 4608 (FIG. 46) to test step 4612 described in detail below. Conversely, if the external model structure 1200 (FIG. 12) represents a parameter, the process proceeds from test step 4608 (FIG. 46) to step 4610.

In step 4610, execution engine 802 (FIG. 8) searches for an item representing the parameter. As previously described in connection with loop step 3348 (FIG. 33E), step 3349, and NEXT step 3350, execution engine 802 (FIG. 8) includes an array of items that represent the parameters of the called function. . The specific parameter represented by the external model structure 1200 (FIG. 12) is the field “parameter”. number "1206. Processing proceeds from step 4610 (FIG. 46) to test step 4616, described in detail below.

  As described above, if external model structure 1200 (FIG. 12) does not represent a parameter, processing proceeds from test step 4608 to test step 4612. In the test step 4612 (FIG. 46), the execution engine 802 (FIG. 8) stores in the field “type” 1204 whether or not the external model structure 1200 (FIG. 12) represents a variable. The determination is made by comparing the obtained data with data indicating that the variable is expressed. If external model structure 1200 (FIG. 12) does not represent a variable, processing proceeds from test step 4612 (FIG. 46) to test step 4616, which will be described in detail later. Conversely, if external model structure 1200 (FIG. 12) represents a variable, processing proceeds from test step 4612 to step 4614.

  In step 4614, the execution engine 802 (FIG. 8) evaluates the variables represented by the external model structure 1200 (FIG. 12). The execution engine 802 (FIG. 8) evaluates the variable by searching for the variable item. In the function structure expressing the subject function, a declaration structure, that is, a declaration structure 1506 (FIG. 16) expresses a variable expressed by the external model structure 1200 (FIG. 12). External model structure 1200 identifies the particular variable represented by storing the identifier of that variable in field “name” 1208. When the external model structure 1200 and the declaration structure 1506 (FIG. 16) express the same variable, the identifier stored in the field “name” 1604 is stored in the field “name” 120 (FIG. 12). Is the same as the assigned identifier. The variable is evaluated by searching the item structure 2700 designated by the “item” 1608 of the declaration structure 1506. Processing proceeds from step 4614 (FIG. 46) to test step 4616.

  As described above, when the external model structure 1200 (FIG. 12) represents neither a parameter nor a variable, that is, when the external model structure 1200 represents a return value item of a function to be called. The process proceeds from test step 4616 to test step 4612. Further, the processing can proceed from step 4614 (FIG. 46) to step 4616 from step 4614. In a test step 4616, the execution engine 802 (FIG. 8) determines whether or not an item representing an external represented by the external model structure 1200 (FIG. 12) is defined. The items are defined because (i) the value of the parameter represented by the external model structure 1200 is defined in step 4610, evaluated to a known value, and the process proceeds to step 4616 (FIG. 46). Or (ii) when the variable represented by the external model structure 1200 (FIG. 12) is initialized at step 4614 and the process proceeds through step 4614 (FIG. 46).

  If the item representing the external represented by the external model structure 1200 (FIG. 12) is not defined, the process proceeds from the test step 4616 (FIG. 46) to the test step 4624 described later. Conversely, if such an item is defined, processing proceeds from test step 4616 to loop step 4618.

Loop step 4618 and NEXT step 4622 form a loop, in which each operation stored in field “operations” 1214 (FIG. 12) of external model structure 1200 is processed. As described above, the number of operations stored in the field “operations” 1214 is the field “num”. For each operation stored in the field “operations” 1214, processing proceeds from loop step 4618 (FIG. 46) to step 4620, where it relates to step 2906 (FIG. 29). In the same manner as described above, an operation is performed on the external represented by the external model structure 1200 (FIG. 12) .When any error is detected by performing the operation on the external, it is described above. As with the method, the user is notified of a programming error, From step 4620 (FIG. 46), processing proceeds through NEXT step 4622 to loop step 4618 where it is stored in the field “operations” 1214 (FIG. 12). next If there is an arithmetic, it is processed: Once all the operations stored in the field “operations” 1214 are processed according to the loop defined by loop step 4618 (FIG. 46) and NEXT step 4622, the process is Proceed to test step 4624.

In test step 4624, execution engine 802 (FIG. 8) specifies that external model structure 1200 (FIG. 12) is to generate a new resource instead of the external represented by external model structure 1200. It is determined whether or not to do. The execution engine 802 (FIG. 8) This determination is made by comparing resources “1218” (FIG. 12) with the Boolean value “true”. If resources “1218” is “false”, processing proceeds from test step 4624 (FIG. 46) through NEXT step 4630 to loop step 4606, where the next external is loop step as described above. 4606 and the NEXT step 4630, according to the loop defined by the field “new”. If resources “1218” (FIG. 12) is “true”, processing proceeds from test step 4624 (FIG. 46) to step 4626.

In step 4626, execution engine 802 (FIG. 8) generates (i) item structures, ie, item structure 2700 (FIG. 27) and resource state structure, ie, resource state structure 3100 (FIG. 31). Stored in the memory 104 (FIG. 1), and (ii) a pointer designating the resource state structure 3100 (FIG. 31) is stored in the field “resource” 2702, and the resource state structure 3100 and the item structure A new resource is generated by associating with 2700 (FIG. 27). Processing proceeds from step 4626 (FIG. 46) to step 4628, where execution engine 802 (FIG. 8) links the new item with the external represented by external model structure 1200 (FIG. 12). Let If the external list structure 1414 (FIG. 15) represents the external, the field “first” is displayed. By storing a pointer specifying the item structure 2700 (FIG. 27) in the field “item” 1608 (FIG. 16) of the declaration structure 1506 specified by the “decl” 1502 (FIG. 15), the item is changed. Associated with that external.

  If External is the return value item of the called function, the result record that was set to NULL at the beginning of the logic flow diagram 3352 (FIG. 46) is set as the new item. When the field “type” 1204 (FIG. 12) of the external model structure 1200 indicates that, the external is a return value item of the called function. If the external is not the return value item of the function to be called, a new item is formed in the field “item” 1608 (FIG. 16) of the declaration structure 1506 representing the external.

From step 4628 (FIG. 46), processing proceeds through NEXT step 4630 to loop step 4606, where the next external is processed as described above. A field “first” of the function model structure 1100 representing the function to be called. “external” 1104 (FIG. 11) and “last” Once all of the externals represented by the external structure in the single linked list of the external structure specified by external "1106 have been processed, processing proceeds from loop step 4606 (FIG. 46) to step 4632. At 4632, the execution engine 802 (FIG. 8) generates a result record as an item obtained by evaluation by emulation of the execution of the called function, as described above in connection with step 4628 (FIG. 46). In addition, this result record is initialized to a NULL value, and when a new resource is generated instead of the return value item, it is set to the value of the return value item.

  After step 4632, processing ends according to logic flow diagram 3352, ie, step 3352 (FIG. 33E). Therefore, by using a model that expresses the behavior of the called function, it is possible to evaluate the call to the function called in the subject function and analyze the evaluation of the execution resource of the called function and the external.

One of the peculiarities of memory group C is that a memory can be treated as a continuously allocated array. In the C language, the following types of memory can be accessed as if the memory were memory allocated as a contiguous block. Such memory types are:
(I) any data of a variable or parameter defined using the instruction “struct” or “array”, ie a composite data structure or array;
(Ii) any pointer passed as a parameter to the function,
(Iii) A memory allocated by execution of a function calloc () or function malloc () defined in the C language.

  In the presently disclosed embodiment of the present invention, a memory bunch is used to model contiguously allocated memory.

  Item structures are assigned to clusters, ie, a continuous array of item structures. Speaking only of the case of an item structure that represents the declaration of a single integer or floating point type variable, this collection includes a single item structure. A group of item structures representing complex type variables, ie, “struct” type and array variables, is represented by a multiple item structure, each of which is a 4-byte array or complex data variable. is there.

  Representing a continuously allocated memory with a continuously allocated item structure allows the detection of several illegal array references. For example, a reference to an item structure within a group of consecutively assigned item structures corresponds to an illegal index of the array represented by that group. Furthermore, the detection of memory leaks as described above is simplified by forming item structures in clusters. For example, if any item structure that is a group is reachable by an external of a function, the external of the function can also be reached by each item structure in the group.

As described above, the item structure 2700 (FIG. 27) includes the field “first”. in Bunch "2708, field" size " of Bunch "2710, field" head " in Bunch "2716 and field" known " bunch size "2718. The field" first ". in “bunch” 2708 is a pointer that designates the first item structure in the collection of item structures including the item structure 2700. When the item structure 2700 is the first item structure in one collection, , Field "first" in “bunch” 2708 specifies the item structure 2700. The field “size”. of Bunch “2710” indicates the number of item structures in the cluster that includes the item structure 2700. In one embodiment, the field “size”. of Bunch "2710 is so defined only in the first item structure in a given crowd.

Field “head” in The “bunch” 2716 is a flag indicating whether or not the item structure 2700 is the first item structure in the group including the item structure 2700. The field “known”. bunch The size “2718” is a flag indicating whether or not the group including the item structure 2700 has a known size. The group has an unknown size. For example, (i) the group is dynamically allocated. When the execution engine 802 (FIG. 8) does not have enough information to calculate the amount of memory required, (ii) the cluster Is passed to the subject function, or (iii) the ensemble has a size that makes it impossible to track each item of the ensemble. bunch If the crowd has an unknown size as indicated by size "2718, the execution engine 802 (FIG. 8) does not check for violations that deviate from the scope of the crowd.

  The computer program in Appendix A is an example of a work such as a Sun Sparkstation® computer system available from Sun Microsystems, Mountain View, Calif. It was compiled and linked using the UNIX operating system SunOS 4.1.3, compiler, and linker provided in the station. In the second example, the computer program of Appendix A was compiled using Microsoft's Visual C ++ 1.5 compiler and linked using its Visual C ++ linker. These compilers and linkers are sold by Microsoft Corporation of Redmond, Washington, USA, and similarly, MS DOS6.2 operating system and Microsoft Windows (registered trademark) 3.1 released by the same company are used. Used on personal computers. A personal computer that can be used includes Art4000S manufactured by Atman Corporation of San Francisco, California. The particular computer language to which the computer program of Appendix A conforms and the computer system in which the computer process defined by the computer program of Appendix A is executed is not an important aspect of the present invention. Those skilled in the art will be able to implement the invention using different computer languages and / or different computer systems by referring to the description herein.

  Appendix A includes a plurality of source code files, which include two alternative implementations of a source code file “readin.c” that defines a plurality of functions and data structures in accordance with another embodiment of the present invention. An example is included. The first example of the source code file “readin.c” appears in frames 64 to 74 of Appendix A, and the second example of the source code file “readin.c” appears in frames 77 to 87 of Appendix A. Appears. It will be appreciated that only one embodiment of the source code file is linked with the rest of Appendix A to form a resource checker in accordance with the principles of the present invention.

  The above description is for explaining the present invention, and the present invention is not limited to this. For example, although the embodiments disclosed herein analyze functions in C language, the principles of the present invention are not limited to the contents of the above description, but can be applied to other computer instruction protocols. Furthermore, it is also possible to provide a computer program that implements the present invention by storing it in some medium. The scope of the invention is limited only by the claims.

FIG. 1 is a block diagram of a computer. FIG. 2 is a block diagram of a computer process component, its component resources, and other components. FIG. 3A is a state diagram illustrating resource modeling according to one embodiment of the present invention. FIG. 3B is a state diagram illustrating resource modeling according to one embodiment of the present invention. FIG. 4A is a state diagram illustrating external modeling according to one embodiment of the present invention. FIG. 4B is a state diagram illustrating external modeling according to one embodiment of the present invention. FIG. 5A is a state diagram illustrating external modeling according to one embodiment of the present invention. FIG. 5B is a state diagram illustrating external modeling according to one embodiment of the present invention. FIG. 6 is a block diagram of a resource checker according to the present invention. FIG. 7 is a block diagram of a resource checker according to the present invention. FIG. 8 is a block diagram of a dynamic inspection engine according to the present invention. FIG. 9 is a logic flow diagram of the analysis of a computer program according to the present invention. FIG. 10 is a logic flowchart of model initialization in the logic flowchart of FIG. FIG. 11 is a block diagram of a function model structure according to an embodiment of the present invention. FIG. 12 is a block diagram of an external model structure according to an embodiment of the present invention. FIG. 13 is a block diagram of a function model structure and two external model structures associated with the function model structure. FIG. 14 is a block diagram of a function structure according to an embodiment of the present invention. FIG. 15 is a block diagram of an external list structure according to an embodiment of the present invention. FIG. 16 is a block diagram of a declaration structure according to an embodiment of the present invention. FIG. 17 is a block diagram of a type structure according to an embodiment of the present invention. FIG. 18 is a block diagram of a field structure according to an embodiment of the present invention. FIG. 19 is a block diagram of a two-field data object. FIG. 20 is a block diagram of two field structures representing the type structure and the data object of FIG. FIG. 21 is a block diagram of a statement structure according to an embodiment of the present invention. FIG. 22 is a block diagram of an expression structure according to an embodiment of the present invention. FIG. 23 is a block diagram of an expression structure, an associated declaration structure, and an associated item structure according to an embodiment of the present invention. FIG. 24 is a logic flow diagram of the analysis of individual computer program components according to an embodiment of the present invention. FIG. 25 is a logic flowchart of one process in the logic flowchart of FIG. FIG. 26 is a one-time logic flow diagram for iterative evaluation of computer program components based on the logic flow diagram of FIG. FIG. 27 is a block diagram of an item structure according to an embodiment of the present invention. FIG. 28 is a logic flow diagram of statement analysis according to an embodiment of the present invention. FIG. 29 is a logic flow diagram for expression evaluation according to an embodiment of the present invention. FIG. 30 is a block diagram of an external structure according to an embodiment of the present invention. FIG. 31 is a block diagram of a resource structure according to an embodiment of the present invention. FIG. 32 is a logic flow diagram of the application of operations to items according to an embodiment of the present invention. It is a block diagram which shows the structure of a fraction drawing. FIG. 33A is a logic flow diagram of operator processing in accordance with an embodiment of the present invention. FIG. 33B is a logic flow diagram of operator processing in accordance with an embodiment of the present invention. FIG. 33C is a logic flow diagram of operator processing in accordance with an embodiment of the present invention. FIG. 33D is a logic flow diagram of operator processing in accordance with an embodiment of the present invention. FIG. 33E is a logic flow diagram of operator processing in accordance with an embodiment of the present invention. FIG. 34 is a logic flow diagram of declaration processing according to an embodiment of the present invention. FIG. 35 is a logic flow diagram of the processing of the “if” statement according to an embodiment of the present invention. FIG. 36 is a logic flow diagram of logical operator processing in accordance with the present invention. FIG. 37 is a logic flowchart of the process in one step of the logic flowchart of FIG. FIG. 38 is a logic flowchart of processing in another process of the logic flowchart of FIG. FIG. 39 is a logic flow diagram of the processing of the “return” statement according to an embodiment of the present invention. FIG. 40 is a logic flow diagram of the processing of the “block” statement according to an embodiment of the present invention. FIG. 41 is a logic flow diagram of resource leak detection according to one embodiment of the present invention. FIG. 42 is a logic flow diagram of external composite state synthesis according to an embodiment of the present invention. FIG. 43 is a logic flow diagram of function model generation from function analysis according to an embodiment of the present invention. FIG. 44 is a logical flowchart of the one-step processing of the logical flowchart of FIG. FIG. 45 is a logic flow diagram for assigning the value of one item to another according to an embodiment of the invention. FIG. 46 is a logic flow diagram of emulation of a called routine according to one embodiment of the present invention.

Claims (1)

A method in a computer for checking for errors in a program component having a plurality of statements, wherein the program component comprises a computer program,
The computer includes storage means for storing the program component, information processing means, and a resource to be processed by the program component, and a resource allocated to and released from one or more program components. ,
Executing a plurality of statements of program components stored in the storage means by the information processing means;
It is determined whether or not the program component is an error by determining whether or not a change in the state of the resource caused by executing the plurality of statements by the information processing means is a predetermined change. Determining by means,
The determining step models the behavior of the resource used by the program component and analyzes the program component by detecting a state violation that may occur in the resource, and an error in the program component. The determination of the occurrence of the error is included in the program component using information on the correspondence between the modeled behavior of the resource and the statement included in the program component. When the statement is executed, the next behavior is estimated using the information of the correspondence relationship, and it is determined whether or not an error occurs due to the estimated behavior .

Images