JP2009193335A - Automatic annotation insertion method of static verification tool - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To save power in detecting an error position when automatic annotation insertion is executed by using a static verification tool and an annotation. <P>SOLUTION: An automatic annotation insertion program is provided with: a source code input means 31, a static verification execution means 32 for executing static verification of a source code; a pointed-out function call item extraction means 33 for extracting an item concerned with a function call from an item which is warned by static verification as a pointed-out function call item; an annotation rule storage means 44 for storing a table for associating a kind of the pointed-out function call item with an annotation corresponding to the kind; an annotation derivation means 34 for deriving the annotation corresponding to the pointed-out function call item; and an annotation insertion means 35 for inserting the annotation derived by the annotation derivation means 34 into the source code. Consequently, the annotation is automatically inserted according to a warning output by the static verification tool concerned with the function call. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to static verification of computer programs.

  Static verification tools are used to check the adequacy of program descriptions. The static verification tool performs source code verification after setting some preconditions in the function call. Generally, a static verification tool has a function for changing this precondition by performing a special description called annotation.

  For example, in the case of the static verification tool SPlint (see Non-Patent Document 1), it is possible to invalidate the premise that “NULL is not passed to the argument” by specifying the annotation “/ * @ null @ * /”. it can. Similarly, by specifying the annotation / * @ out @ * /, it is possible to invalidate the premise that “an uninitialized value is not passed to the argument”.

  The effect of annotation will be described with reference to FIG. In the fourth line of FIG. 4, an annotation of / * @ null @ * / is inserted for the first argument of the function f2. As a result, there is no indication that NULL is passed to f2 in the 12th line. NULL can be passed to the function f2 because it is permitted by the annotation / * @ null @ * / on the fourth line. Conversely, in the 21st line, a NULL pointer reference is pointed out, and it can be seen that a runtime error may occur at this location. This is because the possibility that NULL is passed to the argument p1 is considered by the annotation / * @ null @ * / on the fourth line.

  In the third line of the same example, an annotation of / * @ out @ * / is inserted for the first argument of the function f1. As a result, there is no indication that the uninitialized value is passed to f1 in the eleventh line. The function f1 defined from the 16th line is also created so that there is no problem even if an uninitialized value is passed, and no indication occurs.

  As described above, by using annotations to change the preconditions at the time of function call, not the defects in the parts that violate the preconditions related to function calls, but the places where error can occur at the time of the static verification tool. It can be pointed out.

  Here, it is considered from the viewpoint of wanting to point out a point where a run-time error may occur, not a defect at a point that violates the precondition. In this case, with respect to the preconditions for function calls for which it was pointed out that “the premise is not observed” by the static verification tool itself, it is desirable to obtain a verification result in a state where the precondition is invalidated.

  For example, when the source code shown in FIG. 3 is verified by the above-mentioned SPint, it is pointed out that NULL may be passed to the first argument of f2 on the 12th line. If so, it is desirable to obtain a verification result on the premise that NULL is received for the verification of the function f2. That is, after adding / * @ null @ * / shown in the 4th line of FIG. 3, the indication that NULL may be passed to the first argument of f2 in the 12th line is suppressed, and the 21st line It is desirable that a run-time error indicating a NULL pointer reference occurs.

  The following describes known inventions known to the applicant. Patent Document 1 describes a source code problem prediction technique for the purpose of improving the detection accuracy of a problem location in software static analysis.

  Patent Document 2 discloses a technique for providing an error detection device, an error detection method, and an error detection program that can automatically correct a programming language rule violation without correction by a user. Are listed.

Patent Document 3 includes a step of statically verifying information relating to one or more dynamic checks in a program code, each of the one or more dynamic checks in the program code checking an operation in the program code. There is described a method for checking program code, comprising the steps of:
JP 2007-179488 A Japanese Patent Laid-Open No. 11-296366 Special table 2007-516538 gazette IEEE SOFTWARE January / February 2002 Improving Security Using Extensible Lightweight Static Analysis

  In the conventional static verification tool, as described above, to change the function call precondition based on the indication of the static verification tool itself, and to obtain the verification result on that, the annotation to change the precondition is added. User added manually.

  It is desirable to save labor in detecting errors at runtime using static verification tools and annotations.

  An automatic annotation insertion program according to an embodiment of the present invention includes a source code input unit that reads a source code, a static verification execution unit that performs static verification of a source code by a static verification tool, and a warning by static verification. Indication item storage means for memorizing indication items that are issued, function call indication item extraction means for extracting items related to function calls from indication items as function call indication items, types of function call indication items, and types Annotation rule storage means for storing a table for associating corresponding annotations, annotation derivation means for deriving annotations corresponding to function call indication items extracted by the function call indication matter extraction means in the table, and annotation derivation means The annotations derived by Provided and annotations inserting means for generating annotations inserted source code is inserted into the de, and result output means for outputting annotation insertion source code.

  In the automatic annotation insertion program according to the embodiment of the present invention, a static verification execution unit that performs static verification on a loaded source code by a static verification tool, and a warning is issued by the static verification tool An annotation insertion means for inserting an annotation for stopping a warning from being issued by the static verification tool into the source code.

  According to the present invention, it is possible to save labor for detecting a location where an error occurs at runtime using a static verification tool and an annotation.

  Next, the configuration of an embodiment of the present invention will be described in detail with reference to the drawings. Referring to FIG. 1, the system according to the present embodiment includes a static verification tool 1, an input source code 2, a processing device 3 that operates under program control, a storage device 4 that stores information, and an output source code 5. And output indication item 6. The static verification tool 1 is a software product executed by a computer. The output source code 5 and the output indication item 6 are text information output by the computer.

  As the static verification tool 1, a conventional static verification tool can be applied. In the present embodiment, http: // www. splint. Suppose SPlint published at org /.

  The input source code 2 is source code to which the present system is applied. An example is shown in FIG.

  The processing device 3 includes source code input means 31, static verification execution means 32, function call indication item extraction means 33, annotation derivation means 34, annotation insertion means 35, and result output means 36. . These means are software products that are stored in the storage device and read and executed by the arithmetic control device.

  Each of these means generally operates as follows. The source code input unit 31 reads the input source code 2 and stores it in the source code storage unit 41.

  The static verification execution unit 32 verifies the source code stored in the source code storage unit 41 using the static verification tool 1. When the static verification tool 1 finds a location such as a syntax error and issues a warning message, the indication items including the type of the warning and the location of the source code targeted for the warning are stored in the indication item storage unit 42. Is done.

  The function call indication item extraction unit 33 extracts only indication items related to the function call from the indication items stored in the indication item storage unit 42 and stores them in the function call indication item storage unit 43.

  The annotation deriving means 34 derives the annotation to be added using the indication items stored in the function call indication item storage unit 43 and the rules stored in the annotation rule storage unit 44, and stores them in the additional annotation storage unit 45. Store. The annotation insertion unit 35 inserts the annotation stored in the additional annotation storage unit 45 into the source code stored in the source code storage unit 41. The result output means 36 outputs the source code stored in the source code storage unit 41 and the indication item stored in the indication item storage unit 42 as the output source code 5 and the output indication item 6.

  The storage device 4 includes a source code storage unit 41, an indication item storage unit 42, a function call indication item storage unit 43, an annotation rule storage unit 44, and an additional annotation storage unit 45.

  Each of these storage units generally holds the following information. The source code storage unit 41 holds the input source code 2 to be statically verified, which is read by the source code input unit 31.

  The indication item storage unit 42 holds an indication item for each of the indication points (problem points warned by the static verification tool 1). The contents to be held are the pointed position in the source code, the pointed content, whether or not the pointed item is related to the function call, the called function, and the argument. An example is shown in FIG.

  The function call indication item storage unit 43 holds only items relating to function calls among indication items from the static verification tool. The contents to be held are the indication position, the indication content, the called function, and the argument. An example is shown in FIG.

  The annotation rule storage unit 44 holds a rule for associating the indication content with the annotation to be inserted corresponding to the indication content. An example of the contents is shown in FIG. The example shown in FIG. 8 is used throughout the description of the present embodiment. The annotation rule storage unit 44 is a list of indication contents that the static verification tool may output. The annotation rule storage unit 44 holds an annotation for each indication content, and is used when the annotation insertion unit 35 determines an annotation to be inserted into the source code according to the indication content. An example of this content is manually defined in advance in FIG. 8, and is not changed throughout this embodiment.

  The additional annotation storage unit 45 holds annotations determined to be inserted by the present system. The additional annotation storage unit 45 stores a relationship between an addition target function that is a function to which annotation is added, an argument to which an annotation is added among arguments of each additional target function, and the additional annotation. . An example is shown in FIG.

  Next, the operation of the present embodiment will be described in detail with reference to FIG. 1 and FIG. The source code input means 31 reads the input source code 2 and stores it in the source code storage unit 41 (step A1 in FIG. 2). An example of the source code stored in the source code storage unit 41 is shown in FIG.

  Next, the static verification execution means 32 verifies the source code stored in the source code storage unit 41 using the static verification tool 1 which is a conventional technique, and the obtained indication items are indicated to the indication item storage unit 42. (Step A2 in FIG. 2). At this time, the pointed position (the occurrence point of the pointed item) and the pointed content are stored. As for the items to be pointed out at the function call location, the called function and the argument to be pointed out are also recorded.

  As an example, if the example of the source code stored in the source code storage unit 41 at this time is the one shown in FIG. 5, the indication items stored in the indication item storage unit 42 are shown in FIG. Contents. To explain an example, the indication 11 in FIG. 9 is an indication that “uninitialized value is passed” to & j as the first argument in the function call f1 (& j) on the 11th line of the main function in FIG. It is. Since this is an indication relating to a function call, the “Indication at a function call location” column is Yes.

  Next, the function call indication item extraction means 33 confirms whether there is an indication item in which the “indication at function call location” column is Yes among the indication items stored in the indication item storage unit 42 (FIG. 2). Step A3), if it exists, only the indication item at the function call location is taken out and stored in the function call indication item storage unit 43 (Step A4 in FIG. 2). If not, the process proceeds to step A7.

  As an example, when the contents shown in FIG. 9 are stored in the indication item storage unit 42, since all items are indications at the function call location, all indications 11, 12, and 13 are functions. It is stored in the call indication item storage unit 43. Therefore, the contents of the function call indication item storage unit 43 are as shown in FIG.

  Next, the annotation deriving means 34 extracts the items in which the indication content matches from the rules stored in the annotation rule storage unit 44 for each indication item in the function call indication item storage unit 43, and adds the additional annotation storage unit 45 (step A5 in FIG. 2). At this time, the “called function” column and the “argument” column of the function call indication item storage unit 43 are stored in the “addition target function” column and the “argument” column of the additional annotation storage unit 45, respectively. The annotation string in the annotation rule storage unit 44 is stored in the “additional annotation” column in the additional annotation storage unit 45.

  As an example, assuming that the content shown in FIG. 10 is stored in the function call indication item storage unit 43 and the content of FIG. 8 is stored in the annotation rule storage unit 44, the content of the additional annotation storage unit 45 is as shown in FIG. It becomes the contents of. To explain an example, the indication 11 shown in FIG. 10 has an “indication content” column “passes an uninitialized value”. In FIG. 8, it is rule 1 that the “pointed content” column is “passing an uninitialized value”, so that point 11 is associated with rule 1. The addition 11 of FIG. 11 is generated from both.

  The main purpose of this step is to determine the annotation to be given to the static verification tool based on the items pointed out by the static verification tool. This gist will be described using the example used here.

  SPlint, which is the static verification tool 1 used in the present embodiment, performs verification on the precondition that the function does not receive an uninitialized value unless otherwise specified. However, as indicated by the indication 11 shown in FIG. 10, the static verification tool 1 concludes that an uninitialized value is passed to the first argument of the function f1. Accordingly, when the function f1 is verified thereafter, the precondition that “uninitialized value is not received” should be invalidated for the first argument, that is, the annotation / * @ out @ * / Should be inserted into the first argument of the function f1.

  In order to realize this, the annotation information corresponding to the obtained indication is retained in FIG. 8, and the annotation to be inserted is determined in this step.

  Next, the annotation shown in the additional annotation storage unit 45 is inserted into the source code stored in the source code storage unit 41 by the annotation insertion unit 35, and the result is written back to the source code storage unit 41 (FIG. 2). Step A6). More specifically, the annotation specified in the “addition annotation” column is inserted into the argument specified in the “argument” column of the function specified in the “addition target function” column of the additional annotation storage unit 45. The

  As an example, when the content shown in FIG. 11 is stored in the additional annotation storage unit 45 and the content shown in FIG. 5 is stored in the source code storage unit 41, the content in which the annotation is inserted is shown in FIG. This content is displayed, and this content is written back to the source code storage unit 41. Explaining an example, the annotation “/ * @ out @ * /” is inserted into the first argument of the function f1 by No11 of the additional annotation storage unit 45. This result is / * @ out @ * / in the 03rd line of FIG.

  As described above, when step A6 in FIG. 2 ends, the processing returns to step A2 in FIG. Next, step A2 in FIG. 2 is executed again. Explaining only an example, when the contents of FIG. 6 are stored in the source code storage unit 41, the contents stored in the indication item storage unit 42 are as shown in FIG. The contents different from the first execution of step A2 are stored in the indication item storage unit 42, which is an effect of the annotation insertion. As an example, No. 21 in FIG. 12 receives an indication that an uninitialized value is referenced on the 21st line in FIG. This is because an uninitialized value can be passed to the second argument of the function f2 by the static verification tool because the annotation / * @ out @ * / is inserted into the second argument of the function f2 on the 04th line. It was pointed out as a result of the verification that considered the nature.

  Next, steps A3 and A4 in FIG. 2 are executed again. Explaining only the example, when the contents as shown in FIG. 12 are stored in the indication item storage unit 42, it is the indication 22 that the “indication at the function call location” is Yes. Are extracted and stored in the function call indication item storage unit 43. As a result, as shown in FIG. 13, the content of the function call indication matter storage unit 43 is the content storing only the indication 22.

  Next, step A5 in FIG. 2 is executed again. Explaining only the example, if the content shown in FIG. 13 is stored in the function call indication item storage unit 43 and the content of FIG. 8 is stored in the annotation rule storage unit 44, the content of the additional annotation storage unit 45 is stored. Is the contents of FIG. Explaining an example, the indication 22 shown in FIG. 13 has the “content of indication” column “passing NULL”. In FIG. 8, it is rule 1 that the “pointing content” column is “passing NULL”, and thus point 22 is associated with rule 1. The addition 22 of FIG. 14 is generated from both.

  Next, step A6 in FIG. 2 is executed again. Explaining only the example, when the content shown in FIG. 14 is stored in the additional annotation storage unit 45 and the content shown in FIG. 6 is stored in the source code storage unit 41, the content in which the annotation is inserted is It becomes what is shown in FIG. 7 and is written back to the source code storage unit 41. With the addition 22 in FIG. 14, the annotation / * @ null @ * / is inserted into the first argument of the function f3. This result is / * @ null @ * / in the 05th line of FIG.

  Since step A6 in FIG. 2 is completed, the process returns to step A2 in FIG. 2 again. Next, step A2 in FIG. 2 is executed again. Explaining only an example, when the contents of FIG. 7 are stored in the source code storage unit 41, the contents stored in the indication item storage unit 42 are as shown in FIG.

  Next, step A3 in FIG. 2 is executed again. Explaining only an example, when the contents as shown in FIG. 15 are stored in the indication item storage unit 42, there is no case where “indication at a function call location” is Yes. Accordingly, the process proceeds to step A7.

  Next, the result output means 36 outputs the indication item stored in the indication item storage unit 42 as the output indication item 6, and the source code stored in the source code storage unit 41 as the output source code 5 is particularly processed. And output as it is (step A7 in FIG. 2).

  For example, if the indication item storage unit 42 stores the contents as shown in FIG. 15 and the source code storage unit 41 stores the contents as shown in FIG. Is output. That is, the content of FIG. 15 is output as the output indication item 6 and the content of FIG. 7 is output as the output source code 5.

  The indication items shown in FIG. 15, that is, indications 31 and 32 are not indicated at the function call location, but are referred to an uninitialized value (indication 31) or NULL (indication 32). This is an indication that an error occurs during execution. Further, according to the contents of FIG. 7, it is possible to confirm what annotations have been obtained as a result of adding annotations. As described above, the user of this system can obtain the point where the runtime error occurs without performing the annotation insertion work. The operation of the embodiment of the present invention has been described above.

The system configuration to which the automatic annotation insertion program is applied is shown. The operation of the automatic annotation insertion program is shown. It is an example of the source code to which static verification is applied. It is an example of the source code for demonstrating an annotation. It is an example of source code to which an annotation automatic insertion program is applied. It is an example of the source code in which the annotation is inserted. It is an example of the source code in which the annotation is inserted. Data stored in the annotation rule storage unit is shown. Indicates the indication items stored in the indication item storage unit. Data stored in the function call indication item storage unit is shown. The data stored in an additional annotation memory | storage part are shown. Data stored in the indication item storage unit is shown. Data stored in the function call indication item storage unit is shown. The data stored in an additional annotation memory | storage part are shown. Data stored in the indication item storage unit is shown.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Static verification tool 2 Input source code 3 Processing apparatus 4 Memory | storage device 5 Output source code 6 Output indication 31 Source code input means 32 Static verification execution means 33 Function call indication extraction means 34 Annotation derivation means 35 Annotation insertion means 36 Result output means

Claims (3)

Source code input means for reading source code;
Static verification execution means for executing static verification of the source code by a static verification tool;
An indication item storage means for storing an indication item which is an item for which a warning is issued by the static verification;
A function call indication extracting means for extracting a function call indication from the indication as a function call indication;
Annotation rule storage means for storing a table associating the types of the function call indication items with the annotations corresponding to the types;
In the table, annotation derivation means for deriving the annotation corresponding to the function call indication matter extracted by the function call indication matter extraction means;
Annotation insertion means for generating the annotation insertion source code by inserting the annotation derived by the annotation derivation means into the source code;
An annotation automatic insertion program comprising: a result output means for outputting the annotation insertion source code. An annotation automatic insertion program according to claim 1,
The annotation is a description for stopping the static verification tool from issuing a warning with respect to a matter for which a warning has been issued by the static verification tool. Static verification execution means for executing static verification by a static verification tool on the loaded source code,
An annotation automatic insertion program comprising: annotation insertion means for inserting an annotation for stopping the warning from being issued by the static verification tool to the source code with respect to an item for which a warning has been issued by the static verification tool.

Images