JP2011154568A - Information processing apparatus, program verification method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently verify a program handling recursive data by a model checking method. <P>SOLUTION: An information processing apparatus includes a syntactic analysis means for analyzing a source file to be verified which includes recursive assertion information about recursive data to extract the recursive assertion information, a limited assertion generation means for generating limited assertion information limited to a predetermined number of elements of recursive data from the recursive assertion information, and a verification file generation means for substituting the generated limited assertion information for the recursive assertion information in the source file to be verified to generate a verification file to be program-verified by model checking. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a technique for verifying a program using a model checking method.

  An example of a method for analyzing a program and detecting a defect is described in Patent Documents 1 and 2, and Non-Patent Documents 1 and 2. A model checking method known as a kind of this kind of detection method is disclosed in Patent Document 2 and Non-Patent Document 1. The model checking method is a property that is to be examined in a finite state space consisting of a finite number of “states” and transitions between states that represent the behavior of systems and software. This is a method for examining whether or not it is established by an exhaustive search. In particular, the bounded model inspection method with a limited search depth is attracting attention as an efficient defect detection method. In this method, a bounded model check is applied by converting the program into a finite state space with the combination of the value of the variable in the program and the position in the control flow as a “state”. Since the combination of the values of the variables and the change in the values in the program are traced along the control flow, accurate analysis can be performed.

  One way of expressing the property to be investigated is “Design by Contract” (Non-Patent Document 2). In this way of thinking, in the source code, the precondition indicating the state at the beginning of the function, the postcondition indicating the state at the end of the function, and the invariant condition indicating the state that does not change due to the execution of the function are described as assertions. Verify that the source code is written correctly.

JP 2008-210059 JP 2009-21503 A

F. Ivancic, I. Shlyakhter, A. Gupta, M. Ganai, V. Kahlon, C. Wang, and Z. Yang. Model Checking C Programs Using F-SOFT. In Proc. ICCD’05, 2005. B. Meyer. Applying “Design by Contract”. IEEE Computer, Vol.25, No.10, pages 40-51, 1992.

  However, it is difficult to verify a program that handles recursive data formed by repeatedly connecting variables having the same structure, such as lists and trees, by the above-described model checking method. This is because the number of iterations is not determined, the number of recursive data variables is not determined, and the program cannot be converted to a finite state space.

  More specifically, a program that handles recursive data is described as a recursive call of a recursive function in which a part of recursive data passed as an argument is processed, and the same function is recursively called for the remaining part to be processed. However, the variables defined in the recursive function are instantiated as different variables for each call, such as a variable in the first call, a variable in the second call,... A variable in the Nth call. The For this reason, if the number of recursive calls is not determined, the number of variables defined in the recursive function is not determined, and the program cannot be converted to a finite state space. As a result, the model checking method cannot be applied.

  Based on the above, an object of the present invention is to solve the above problems.

In order to achieve the above object, an information processing apparatus according to the present invention provides:
Parsing means for analyzing the source file to be verified including recursive assertion information on recursive data and extracting the recursive assertion information;
From the recursive assertion information, limited assertion generation means for generating limited assertion information in which the number of elements of the recursive data is limited to a predetermined number;
In the verification target source file, the recursive assertion information is replaced with the generated limited assertion information, and verification file generation means for generating a verification file for performing program verification by model checking;
It is characterized by providing.

In order to achieve the above object, a program verification method according to the present invention includes:
A parsing step for analyzing the source file to be verified including recursive assertion information on recursive data and extracting the recursive assertion information;
From the recursive assertion information, a limited assertion generation step for generating limited assertion information in which the number of elements of the recursive data is limited to a predetermined number;
In the verification target source file, the recursive assertion information is replaced with the generated limited assertion information, and a verification file generating step for generating a verification file for performing program verification by model checking;
It is characterized by including.

In order to achieve the above object, a program according to the present invention provides:
On the computer,
A parsing step for analyzing the source file to be verified including recursive assertion information on recursive data and extracting the recursive assertion information;
From the recursive assertion information, a limited assertion generation step for generating limited assertion information in which the number of elements of the recursive data is limited to a predetermined number;
In the verification target source file, the recursive assertion information is replaced with the generated limited assertion information, and a verification file generating step for generating a verification file for performing program verification by model checking;
Is executed.

  According to the present invention, a program that handles recursive data can be efficiently verified by a model checking method.

1 is a schematic diagram showing an overall configuration of a system as an embodiment of the present invention. It is the schematic which shows the flow of the whole process of the system as embodiment of this invention. It is the schematic which shows the flow of the assertion process in the system as embodiment of this invention. It is a figure which shows the production | generation process of the precondition and the postcondition in the system as embodiment of this invention. It is a figure which shows the data type information and function call information of a source code in the system as embodiment of this invention. In the system as an embodiment of the present invention, it is a figure showing information about recursive assertion in source code. In the system as an embodiment of the present invention, it is a figure explaining statement about transition closure. It is a figure which shows the specific example of the data type and function of a source code in the system as embodiment of this invention. In the system as an embodiment of the present invention, it is a diagram showing an example of recursive assertion in the source code. It is a figure which shows the specific example of the data type information of a source code, and function call information in the system as an Example of this invention. In the system as an embodiment of the present invention, it is a diagram showing a specific example of information about recursive assertion in the source code. It is a figure which shows the specific example of the process which limits the number of elements of the precondition in a source code in the system as an Example of this invention. It is a figure which shows the specific example of the process which limits the number of elements of the postcondition in a source code in the system as an Example of this invention. It is a figure which shows the specific example of the process which limits the number of elements of the postcondition in a source code in the system as an Example of this invention. It is a figure which shows the specific example of the process which limits the number of elements of the postcondition in a source code in the system as an Example of this invention. It is a figure which shows the specific example of the file for verification produced | generated by asserting a source code and substitution of a call destination in the system as an Example of this invention.

  Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the drawings. However, the components described in the following embodiments are merely examples, and are not intended to limit the technical scope of the present invention only to them.

(First embodiment)
<Device configuration>
FIG. 1 is a diagram showing a schematic configuration of an information processing apparatus 100 as the first embodiment of the present invention. The information processing apparatus 100 includes a verification target specification module 110, a syntax analysis module 120, a limited assertion generation module 130, a recursive function replacement module 140, a verification file output module 150, an external tool execution module 160, and a file storage unit 170. Among these modules, the verification target designating module 110 receives as input the files and functions to be verified and the number of elements for limiting the number of recursive data repetitions from the user. The parsing module 120 reads the verification target source file designated as the verification target from the file storage unit 170, analyzes the source code, and analyzes data type information related to the verification target function, function call information, and recursive data. Extract assertion information about. The limited assertion generation module 130 generates a limited assertion (that is, limited assertion information) in which the number of elements is limited to a specified predetermined number based on the extracted data type information and the recursive data assertion. The recursive function replacement module 140 refers to the extracted function call information. If the specified function is a recursive function, the recursive function replacement module 140 eliminates the recursive call and returns a normal function to the dummy function to which a limited assertion is given. Convert to call.

  The verification file output module 150 replaces the contents of the designated source file with the generated limited assertion for the recursion data assertion. Further, when there is a recursive call, “recursive call” is replaced with “call to a dummy function with a limited assertion” to generate a verification file for performing model checking, and the file storage unit 170 To store. The external tool execution module 160 executes the program verification module 190 based on the existing model check using the generated verification file.

<Overall verification process flow>
Next, the overall operation of the present embodiment will be described in detail with reference to the flowcharts of FIGS. 1, 2, and 3. The verification target designating module 110 accepts designation of the verification target file name, verification target function name, and number of elements from the user (S201).

  The syntax analysis module 120 reads the source file corresponding to the specified verification target file name from the file storage unit 170 (S202), and performs syntax analysis of the source code and the assertion (S203).

<< Syntax analysis of source code and assertion >>
Here, the syntax analysis of the source code and the assertion (S203) will be described in detail with reference to FIG. 3, FIG. 5, FIG. 6, and FIG. The syntax analysis module 120 analyzes the data type of the source code (S301), and registers the result as data type information (501 in FIG. 5). Further, the function call relationship is analyzed (S302), and the result is registered as function call information (502 in FIG. 5).

  Next, the syntax analysis module 120 analyzes the assertion (S303), and if the assertion relates to recursive data, registers recursive assertion information (601 to 606 in FIG. 6) according to the type (S304). ~ S313).

  Here, first, in step S305, it is determined whether or not the statement is related to transitional closure. As indicated by reference numeral 701 in FIG. 7, transition closure (TC) is a set of elements that can be reached by tracing a transition variable from an element as a starting point until reaching the end. TC is an identifier indicating that the data structure is transitive closure. If it is determined that the source code includes an assertion about transitive closure, “TC name” that is an identifier of transitive closure is registered in the TC list information (601 in FIG. 6) (S306), and the content of the assertion, that is, The starting point, transition member, and end point are registered as TC information (602 in FIG. 6).

  Next, in step S307, it is determined whether or not it is an assertion regarding the value setting of the transition closure element (702 in FIG. 7). If the assertion is related to the value setting of the transition closure element, the content of the assertion is registered in the element value setting information (603 in FIG. 6) (S308). Furthermore, if it is an assertion regarding the value change of the element of transitional closure (703 in FIG. 7) in step S309, the content of the assertion is registered in the element value change information (604 in FIG. 6) (S310).

  Further, if it is an assertion regarding the division of the transitional closure (704 in FIG. 7) in step S311, “TC1” and “TC2” as the identifiers of the transitional closures thus divided are registered in the TC list information (601 in FIG. 6). The contents of the assertion are registered in the divided TC information (605 in FIG. 6) (S312). At this time, “TC1” and “TC2” are registered as different divided TC information, and the condition for TC2 is registered as a result of negating the condition for TC1.

  Otherwise, if it is an assertion regarding transitional closure (705 in FIG. 7), the content of the assertion is registered in the TC connection information (606 in FIG. 6) (S313). At this time, if the join target is already registered in the TC list information (601 in FIG. 6), the join target TC classification is set to “TC”, and if not, “element” is set.

<< Limitation of elements >>
Returning to FIG. 2, when the analysis of the source code and the assertion is completed in step S203, the process proceeds to step S205 and the subsequent steps, and the limited element number N is incremented from 0 to the number of elements specified in S201 (S219). The generation process (S207 to S217) is repeated a plurality of times. Specifically, first, 0 is substituted for the limited element number N (S205), and in step S207, it is determined whether N is smaller than the specified element number. If N is smaller than the specified number of elements, the process proceeds to step S209, and the limited assertion generation module 130 sets the number of transition closure elements to the limited number of elements N based on the data type information and the recursive assertion information obtained by the syntax analysis. A limited assertion is generated (S209).

  Next, the recursive function replacement module 140 refers to the function call information (502 in FIG. 5) and determines whether or not the specified verification target function is performing a recursive call (S211). If the specified verification target function has made a recursive call, the process advances to step S213 to create a dummy function having the same arguments, function type, and assertion as the verification target function, and change (replace) the recursive call to a dummy function call. )

  Next, the verification file output module 150 generates processing results of the limited assertion generation module 130 and the recursive function replacement module 140 as verification files, and outputs them to the file storage unit 170 (S215). Finally, the external tool execution module 160 receives the verification file as an input, and executes the program verification module 190 based on the conventional model checking (S217) to verify that the source code is correctly described in light of the limited statement. A plurality of limited assertion information in which the number of elements of the recursive data is limited to the number N of elements from 0 to the specified number of elements (predetermined number) by repeating the above-described limited assertion generation process (S207 to S217) a plurality of times. Generate.

<< Limitation Statement Generation Process >>
The generation process of the limited assertion of the number of elements N performed by the limited assertion generation module 130 performed in step S209 of FIG. 2 will be described in detail with reference to FIGS. First, the limited assertion generation module 130 generates a precondition representing a data structure corresponding to the limited element number N (S401). That is, with reference to the TC information (602 in FIG. 6), a precondition is generated such that an unused memory address is allocated to an element that arrives through the transition member 0 to N−1 times from the starting point. Further, a precondition is generated such that an end point is assigned to an element that reaches N times from the starting point via the transition member.

  Further, the limited assertion generation module 130 refers to the TC information and the element value setting information (603 in FIG. 6), and for each element that can be reached through the transition member 0 to N−1 times from the starting point, the value of the member A pre-condition is generated so as to match the condition (S402). Next, the limitation assertion generation module 130 refers to the element value change information (603 in FIG. 6) and determines whether information is registered (S403). If the information is registered, a postcondition indicating that the structure of the recursive data does not change is generated (S404). That is, each element that can be reached through the transition member 0 to N-1 times from the result variable of the element value change information reaches through the transition member 0 to N-1 times from the starting point of the TC information at the start of the function. Generate a postcondition that indicates that each element is equal.

  For each element that arrives from the result variable via the transition member 0 times, 1 time,... N-1 times, the member of the element satisfies the matching condition and the changing condition, and the matching condition and the changing condition Post-conditions are generated in which the values of members not involved in the change do not change and the values of members of other elements also do not change (S405 to S407).

  Next, the limited assertion generation module 130 determines whether or not the TC combination information (606 in FIG. 6) is registered (S408). When the TC connection information is registered, a combination is obtained such that the sum of the number of elements to be combined whose TC classification is “TC” is the limited number of elements N (S409). For example, when there are TC1 and TC2 to be joined whose TC classification is “TC” and the number of limited elements is 2, the combinations of the number of elements of TC1 and TC2 are (2, 0), (1, 1), ( 0,2) is required. The limited assertion generation module 130 repeats generation of the postcondition for each combination (S410 to S413).

  As the post-condition, first, a condition for the data structure is generated (S411). It is assumed that the recursive data at the start of the function is T0, the recursive data obtained by dividing T0 is T1 and T2, and the element e having the same data type as the recursive data is combined in the order of T1, e, and T2. When the TC list information is referred to based on the TC / element name of the TC combination information, the divided TC information related to TC1 and TC2 is known. When the TC list information is referred to based on the referenced TC name of the divided TC information, the TC0 information is related to TC0. TC information is known.

  When the combination of TC1 and TC2 is (2, 0), each element that arrives from the result variable through the transition member through 0 to 1 transition is 0 to 1 through the transition member from the starting point of TC0. Postconditions are generated that are equal to each element reached in the transition. Further, a post-condition is generated such that an element that arrives in two transitions from the result variable is equal to e, and an element that arrives in three transitions from the result variable is equal to the end of the TC information of TC0.

  When the combination of TC1 and TC2 is (1, 1), the element that arrives with 0 transitions from the result variable via the transition member is the element that reaches with 0 transitions via the transition member from the starting point of TC0. A postcondition is generated such that an element that is equal and arrives in one transition from the result variable is equal to e. In addition, the element that arrives in two transitions from the result variable is equal to the element that arrives in one transition from the starting point of TC0 via the transition member, and the element that arrives in three transitions from the result variable is the TC information of TC0 A postcondition is generated that is equal to the end of.

  When the combination of TC1 and TC2 is (0, 2), a postcondition is generated such that an element that arrives in 0 transitions via a transition member from the result variable is equal to e. In addition, the element that arrives from the result variable in 1 to 2 transitions is equal to the element that arrives in 0 to 1 transition from the starting point of TC0 via the transition member, and the element that arrives in 3 transitions from the result variable is A postcondition is generated that is equal to the end of the TC0 TC information.

  After the generation of the postcondition for the data structure, the limit assertion generation module 130 generates a postcondition regarding the value of each element (S412).

  When the combination of TC1 and TC2 is (2, 0), each member of each element that arrives from the result variable via the transition member through 0 to 1 transition is 0 times through the transition member from the starting point of TC0. A postcondition is generated that is equal to the member of each element reached in one transition.

  When the combination of TC1 and TC2 is (1, 1), each member of the element that arrives from the result variable via the transition member with 0 transitions reaches 0 transition through the transition member from the starting point of TC0 Postconditions that are equal to each member of the element to be generated are generated. Further, post-conditions are generated such that each member of the element that arrives in the two transitions from the result variable is equal to each member of the element that arrives in one transition from the starting point of TC0 via the transition member.

  When the combination of TC1 and TC2 is (0, 2), each member of an element that arrives from the result variable in 1 to 2 transitions is an element that arrives in 0 to 1 transition from the starting point of TC0 via the transition member Postconditions that are equal to each member of are generated.

  As described above, in the present embodiment, a precondition relating to recursive data for which the number of elements is not determined is replaced with an assertion in which the number of elements is limited to a specified number or less, and a recursive call whose number of calls is not determined Replace with a normal function call. As a result, the number of variables in the program to be verified can be limited to a finite number, and the program to be verified can be converted to a finite state space, enabling comprehensive verification by model checking. It becomes. That is, in accurate verification of a program using the model checking method, it is possible to verify recursive data whose number of elements is unknown and recursive functions whose number of calls is unknown, which has been difficult to verify in the past. In other words, the correctness of data with a recursive structure for which the number of elements has not been determined or a program with a recursive function call for which the number of calls has not been determined is checked against the assertions such as preconditions and postconditions described in the source file. It can be verified by model checking.

<Specific example>
Next, as shown in FIG. 8, the data type “struct Node” with recursion and the function “put” that handles this data type and makes a recursive call to itself are taken as an example for the verification described above as an embodiment. A specific example of file generation will be described. The source code to be verified is shown in 1601 (line numbers 1 to 18) in FIG. Figure 9 shows the recursive assertion for the function put. In FIG. 9, @pre on the second line indicates that the subsequent expression is a precondition, and @post on the fourth line indicates that the subsequent expression is a postcondition.

  The expression __tc (TC0, p, "next", NULL) on the second line as a precondition is a variable that can be reached by the member variable next starting from the argument p until the next value becomes NULL. Indicates that the set is named “TC0”.

  The expression __tc_value (TC0, e, (e-> next == NULL) || (e-> key <e-> next-> key))) on the third line is e with respect to each element e of the set TC0. If the value of the member variable next is not NULL, it indicates that the value of the member variable key of e is smaller than the value of the key of the element reached in one transition from e to next.

  The expression __tc_modify (__return, TC0, e, e-> key == k, e-> value == v) on the 4th line is used if the set TC0 has an element whose member key has the same value as the argument k. The element member value is changed to the same value as the argument v, indicating that the origin of the set containing the changed result is the return value of the function.

  If the set TC0 has no element whose member key has the same value as the argument k, the expression on the 4th line is evaluated as false, and the 6th and subsequent lines are evaluated according to the logical meaning of the OR of the 5th line. Is evaluated. The expression __fresh (e) && e-> key == k && e-> value == v on line 6 assigns an unused memory address to the variable e, and the members key and value of e are the arguments k and Indicates that it has the same value as v.

  The expression __tc_split (TC0, TC1, TC2, d, d-> key <k) on line 7 names the set of elements whose member key in the set TCO has a value smaller than the argument k as TC1, and sets the other elements It shows k which named the set TC2. The expression __tc_join (__return, “next”, TC1 && e && TC2) on the 8th line does not change the joining order of elements in TC1 and TC2, but changes each element of TC1 Indicates that the return value of the function is the starting point of the set resulting from the join.

  It is assumed that a file including 2 as the number of elements, “put” as the verification target function name, and “put” as the verification target file name is given to the verification target specifying module 110.

  The parsing module 120 reads the source file to be verified (step S201 in FIG. 2), analyzes the source code (1601 in FIG. 16), and analyzes the data type information (1011 in FIG. 10) on the data type struct Node. The function call information (1021 in FIG. 10) for the function put is obtained. Further, the recursive assertion (FIG. 9; details omitted in line 5 of FIG. 16) accompanying the source code is analyzed to obtain recursive assertion information (1111 to 1161 of FIG. 11) for the function put (step S202 of FIG. 2). .

  The case where N = 2 in the repetition of the limited element number N = 0, 1, and 2 with respect to the designated element number 2 (steps S205 to S219 in FIG. 2) will be described as an example. The limitation assertion generation module 130 refers to the TC information (1121 in FIG. 11) and generates a precondition (row 2 ′ in FIG. 12) representing a data structure in which the number of elements is 2 (step S401 in FIG. 4). ). This precondition indicates that an unused memory address is assigned to each of the elements that have transitioned once through the starting points p and next of the set TC0, and NULL that is the end of TC0 is allocated to the element that has transitioned twice. Yes.

  The limitation assertion generation module 130 refers to the element value setting information (1131 in FIG. 11) and generates a precondition (row 3 'in FIG. 12) for the element value (step S402 in FIG. 4). This precondition indicates that the value of the member key of p is smaller than the value of key of the element that has transitioned once from p to next. Since the element that has changed twice is NULL, which is a representative value of an invalid address, the relationship between the key value of the element that has changed once and the key value of the element that has changed twice is not included in the precondition.

  Regarding the post-condition, the limited assertion generation module 130 first confirms that there is information by referring to the element value change information (1141 in FIG. 11) (step S403 in FIG. 4), and how the recursive data structure is. A post-condition (row 4a ′ in FIG. 13) indicating whether or not to change is generated (step S404 in FIG. 4). Here, the postcondition (line 4a ′ in FIG. 13) indicates that the structure of the recursive data starting from the return value of the function is the same as the structure starting from the argument p at the start of the function. After the generation of the post-condition regarding the data structure, a post-condition (rows 4b 'and 4c' in FIG. 13) indicating how the element value has been changed is generated (steps S405 to 407 in FIG. 4). The row 4b 'in FIG. 13 indicates that the member value is changed to the argument v for the element indicated by the return value, and the other elements and members are not changed. The row 4c 'in FIG. 13 indicates that the member value changes to the argument v with respect to the element transitioned from the return value via the member next, and the other elements and members do not change. After generating the postcondition when the data structure does not change in this way, the limited assertion generation module 130 confirms that there is information by referring to the TC combination information (1161 in FIG. 11) (step of FIG. 4). S408), the combination of the bonds is calculated (step S409 in FIG. 4).

  In the TC connection information, there are TC1 and TC2 to be combined whose TC classification is TC, and under the restriction of the number of limited elements N = 2, the combinations of the numbers of elements of TC1 and TC2 are (2, 0), (1, 1) and (0, 2). For these three types, the limited assertion generation module 130 repeats generation of the postcondition (steps S409 to S412 in FIG. 4). For the combination (2, 0), the post-conditions regarding the data structure are the 8a 'and 7a' lines in FIG. In line 8a ', the first transition destination via the return value and next is the same element as TC, the second transition destination is a new element to which unused memory is allocated, and the third transition destination. Indicates that the end of TC0 is NULL. Line 7a 'indicates that each member key of element p-> next that has transitioned once from arguments p and p at the start of the function is smaller than k, that is, these two elements belong to TC1. ing.

  The post-condition regarding the element value is the 6a 'line in FIG. Here, the value of each member of the first transition destination via the return value and next is the same value as each member of the corresponding element in TC0, and the members key and value of the second transition destination are the arguments k and v It is the same value as. The post-condition regarding the data structure for the combination (1, 1) is 8b ′ and 7b ′ in FIG. 14, and the post-condition regarding the element value is the post-condition regarding the data structure for the 6b ′ line and the combination (0, 2) in FIG. The conditions are the 8c ′ and 7c ′ lines in FIG. 15 and the post-condition regarding the element value is the 6c ′ line in FIG. 15. The combination (2, 0) and the values of the structure and elements as shown in the supplementary column of FIG. Is shown. The recursive function replacement module 140 confirms in the function call information (1021 in FIG. 10) that there is a recursive call that the referenced function of the function put is put itself (step S207 in FIG. 2). Then, a dummy function of a non-recursive function having the same return value and argument as the function put is generated, and a recursive call from the function put to put itself is converted into a normal function call to the dummy function. The verification file output module 150 outputs the result of the limited assertion generation module 130 and the recursive function replacement module 140 as a verification file.

  In FIG. 16, lines 4b ′ to 4c ′ in the verification file 1602 after replacement are dummy functions generated by the recursive function replacement module, and line 15 ′ is a recursive call to put itself as a call to the dummy function. It is a changed place. In FIG. 16, the 4a ′ line and the 5 ′ line are omitted for the sake of simplification, but in reality, there are assertions limited to the number of elements described in FIGS. 12 to 14.

(Other embodiments)
The present invention can also be applied to a case where a verification program that realizes the functions of the above-described embodiments is supplied directly or remotely to a system or apparatus. Therefore, in order to realize the functions of the present invention on a computer, a program installed in the computer, a medium storing the program, and a WWW server that downloads the program are also included in the scope of the present invention.

Claims (8)

Parsing means for analyzing the source file to be verified including recursive assertion information on recursive data and extracting the recursive assertion information;
From the recursive assertion information, limited assertion generation means for generating limited assertion information in which the number of elements of the recursive data is limited to a predetermined number;
In the verification target source file, the recursive assertion information is replaced with the generated limited assertion information, and verification file generation means for generating a verification file for performing program verification by model checking;
An information processing apparatus comprising: The limited assertion generation means includes:
Generating a plurality of limited assertion information in which the number of elements of the recursive data is limited to the number of elements from 0 to the predetermined number;
The verification file generation means includes:
In the verification target source file, the recursive assertion information is replaced with each of the generated plurality of limited assertion information, and a plurality of verification files for performing program verification by model checking are generated. The information processing apparatus according to claim 1. The limited assertion generation means includes:
A precondition in which the number of elements of the recursive data is limited to each number of elements from 0 to the predetermined number, and a postcondition indicating how the structure of the recursive data changes are generated. Item 3. The information processing apparatus according to item 1 or 2.   The recursive assertion information is information indicating an assertion related to transitive closure, and the limited assertion generation unit is configured to change the number of elements of transitive closure from 0 based on data type information obtained by syntax analysis by the syntax analysis unit. The information processing apparatus according to claim 1, 2, or 3, wherein an assertion limited to a limited number of elements up to a predetermined number is generated.   5. The verification file generation means further replaces the recursive call of the function with a call of a dummy function when the verification target source file includes a recursive call of the function. The information processing apparatus according to any one of claims.   The verification file generation means creates a dummy function having the same arguments, function type, and assertion as the function when the function in the verification target source file performs a recursive call, and makes the recursive call a dummy function. The information processing apparatus according to claim 1, wherein the information processing apparatus is changed to a call of A parsing step for analyzing the source file to be verified including recursive assertion information on recursive data and extracting the recursive assertion information;
From the recursive assertion information, a limited assertion generation step for generating limited assertion information in which the number of elements of the recursive data is limited to a predetermined number;
In the verification target source file, the recursive assertion information is replaced with the generated limited assertion information, and a verification file generating step for generating a verification file for performing program verification by model checking;
A program verification method comprising: On the computer,
A parsing step for analyzing the source file to be verified including recursive assertion information on recursive data and extracting the recursive assertion information;
From the recursive assertion information, a limited assertion generation step for generating limited assertion information in which the number of elements of the recursive data is limited to a predetermined number;
In the verification target source file, the recursive assertion information is replaced with the generated limited assertion information, and a verification file generating step for generating a verification file for performing program verification by model checking;
A program characterized by having executed.

Images