Code analysis path pruning method and device, equipment and storage medium

Abstract

The application provides a code analysis path pruning method and device, equipment and a storage medium, wherein the method comprises the following steps: extracting control flow information of to-be-analyzed code and splitting a composite conditional statement, generating a control flow graph corresponding to the to-be-analyzed code, a node block of the control flow graph representing an execution unit or a conditional judgment unit, and an edge representing a path direction of the control flow; marking a conditional judgment unit to be tracked as a record unit; traversing the control flow graph in a multi-branch parallel mode, performing normalization processing on the statement in the traversal process, if the conditional statement of a certain record unit is first appeared in a single branch, maintaining all possible conditional states, otherwise, querying the value of the conditional state corresponding to the conditional statement from a dynamically maintained list, and pruning the out-degree edge of the record unit which does not match the conditional state; for the first appearance of the conditional statement and the unpruned condition after the query, a copy of the dynamically maintained list is generated, which is used for independent update and query in the subsequent conditional state of each branch.

Description

Technical Field

[0001] This invention relates to the field of code analysis technology, and in particular to a code analysis path pruning method, apparatus, device, and storage medium. Background Technology

[0002] Code analysis refers to the review of source code through automated tools or manual inspection. As software systems grow in scale, especially for complex systems developed using C / C++ in industrial applications, the complexity and diversity of their syntax itself have become a significant challenge for code analysis and defect detection.

[0003] In related technologies, static analysis tools are often used for comprehensive code analysis. However, when faced with complex syntactic structures such as multi-level nested loops, recursive calls, or conditional branches, they often encounter computational difficulties due to the exponential growth in the number of control flow paths. Theoretically, the time complexity of traditional full-path traversal analysis can reach O(2^n). For example, in code with nested conditional statements like if(A){if(B){...}}, the branch paths grow exponentially with the nesting depth. For particularly complex code, the computation time required to exhaustively search for paths may exceed the acceptable range for engineering. To balance efficiency and accuracy, existing tools have to compromise on complex path analysis, resulting in a high false negative rate. In addition, existing code analysis uses both sequential and parallel exploration, but the data storage method of the global state table in parallel processing leads to thread contention, while completely independent storage will result in significant storage overhead.

[0004] Based on the above analysis of the development status of this technology field, existing technologies lack solutions for pruning control flow graphs by traversing them in a multi-branch parallel manner, pruning impossible execution paths in the code path based on clearly defined conditional statements, and creating a dynamically maintained list copy for independent recording when a new branch is generated. Summary of the Invention

[0005] The purpose of this invention is to provide a code analysis path pruning method, apparatus, device, and storage medium, which aims to solve the above-mentioned problems in the prior art.

[0006] According to a first aspect of the present invention, a code analysis path pruning method is provided, comprising:

[0007] Extract the control flow information of the code to be analyzed and split the compound conditional statements to generate the control flow graph corresponding to the code to be analyzed. In the control flow graph, the node blocks represent the execution unit or condition judgment unit, and the edges represent the path direction of the control flow.

[0008] Mark the condition judgment unit that needs to be tracked as a recording unit;

[0009] The control flow graph is traversed in a multi-branch parallel manner. The conditional statements used in the traversal process are normalized. If the conditional statement of a certain record cell appears for the first time in a single branch, all possible conditional states are maintained. Otherwise, the value of the corresponding conditional state of the conditional statement is queried from the dynamically maintained list, and out-degree edges of record cells that do not match the conditional state are pruned.

[0010] For the first occurrence of a conditional statement and cases where no pruning has been performed after a query, a copy of the dynamically maintained list is generated and used for independent updates and queries under subsequent branch condition states.

[0011] According to a second aspect of the present invention, a code analysis path pruning apparatus is provided, comprising:

[0012] The control flow graph generation module is used to extract control flow information from the code to be analyzed and split compound conditional statements to generate the control flow graph corresponding to the code to be analyzed. In the control flow graph, the node blocks represent execution units or condition judgment units, and the edges represent the path direction of the control flow.

[0013] The tracking marker module is used to mark the condition judgment units that need to be tracked as recording units;

[0014] The traversal and pruning module is used to traverse the control flow graph in a multi-branch parallel manner. The conditional statements used in the traversal process are normalized. If the conditional statement of a certain record cell is the first occurrence in a single branch, all possible conditional states are maintained. Otherwise, the value of the corresponding conditional state of the conditional statement is queried from the dynamically maintained list, and out-degree edges that do not match the conditional state of the record cell are pruned.

[0015] The list update module is used to generate a dynamically maintained copy of the list for the first occurrence of a conditional statement and for cases where the query has not been pruned. This copy is then used for independent updates and queries under subsequent branch conditions.

[0016] According to a third aspect of the present invention, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the code analysis path pruning method provided in the first aspect of the present disclosure.

[0017] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, on which an implementation program for information transmission is stored, wherein when executed by a processor, the program implements the steps of the code analysis path pruning method provided in the first aspect of the present disclosure.

[0018] The technical solution provided by the embodiments of the present invention has the following beneficial effects: it proposes a code analysis method based on control flow graph path pruning, which explicitly uses conditional state-based pruning logic and does not analyze invalid paths, thereby improving the efficiency of code analysis to support in-depth analysis of more complex code; it adopts a multi-branch parallel approach to traverse the control flow graph to accelerate the coverage of different paths, and uses the method of generating copies when generating new branches to maintain an independent database, which avoids recording too much duplicate data completely independently while reducing the complexity of thread contention caused by global state storage.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in one or more embodiments of this specification or in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart of the code analysis path pruning method according to an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram of the control flow graph of Embodiment 2 of the present invention;

[0023] Figure 3 This is a schematic diagram of the pruning process in Embodiment 2 of the present invention;

[0024] Figure 4 This is a schematic diagram of the control flow graph of Embodiment 3 of the present invention;

[0025] Figure 5 This is a schematic diagram of the pruning process in Embodiment 3 of the present invention;

[0026] Figure 6 This is a schematic diagram of the code analysis path pruning device according to an embodiment of the present invention;

[0027] Figure 7 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0028] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0029] Method Example 1

[0030] According to an embodiment of the present invention, a code analysis path pruning method is provided. Figure 1 This is a flowchart of the code analysis path pruning method according to an embodiment of the present invention, such as... Figure 1 As shown, the code analysis path pruning method according to an embodiment of the present invention specifically includes:

[0031] In step S110, the control flow information of the code to be analyzed is extracted and the compound conditional statements are split to generate the control flow graph corresponding to the code to be analyzed. The nodes of the control flow graph represent execution units or conditional judgment units, and the edges represent the path direction of the control flow. Specifically, this includes:

[0032] Static analysis tools are used to identify the lexical and syntactic structure and control flow logic in the code to be analyzed, and an initial flow graph is generated.

[0033] The AND and OR logic statements in the initial flow graph are split into independent conditional statements, and corresponding conditional judgment units are generated to replace the original composite conditional units. The AND logic statement is in the form of A&&B, which is true when all conditions are true at the same time. The OR logic statement is in the form of A||B, which is true when any condition is true. In the embodiment of the present invention, it is split into the judgment of conditional statement A and conditional statement B respectively.

[0034] All node blocks except the condition judgment unit are used as execution units. The execution units are used for logical judgment and execution under other normal conditions. The execution result of the execution unit can update the relevant value in the record unit. The node block is called BLOCK.

[0035] In this embodiment of the invention, the flow graph is in CFG form.

[0036] In step S120, the condition judgment unit that needs to be tracked is marked as a recording unit, specifically including:

[0037] Within a function or within a function, if the frequency of a conditional statement corresponding to a certain conditional judgment unit is higher than the first preset threshold, or the frequency of processing of variables in the conditional statement within the execution unit is higher than the second preset threshold, then the corresponding conditional judgment unit is marked as a record unit.

[0038] The marking process is equivalent to a preprocessing process before pruning is performed. Information that appears multiple times in the initial traversal of the BLOCK is key information that may be used for pruning. Preferably, whether the variable value in the conditional statement has been modified can also be used as a condition for whether it needs to be tracked. Condition judgment units other than the recording unit are not pruned or recorded.

[0039] In step S130, the control flow graph is traversed in a multi-branch parallel manner. The conditional statements used during the traversal are normalized. In a single branch, if the conditional statement of a certain record cell is appearing for the first time, all possible conditional states are maintained; otherwise, the value of the corresponding conditional state is retrieved from the dynamically maintained list. Out-degree edges of record cells that do not match the conditional state are pruned. Specifically, this includes:

[0040] Starting from the entry unit of the control flow graph, a multi-branch parallel approach is used for traversal. That is, if there are two conditional states, true and false, for the same unit, a new branch is generated to explore all possible paths in parallel. Subsequent pruning removes unnecessary code branches to prevent the amount of parallel processing from becoming too large, and each branch is executed independently.

[0041] Conditional statements typically contain operators such as >, >=, <, <=, ==, and !=, which slows down subsequent lookups. Therefore, a normalization process is designed as follows:

[0042] Normalize conditional statements in node blocks that use the operators greater than >, greater than or equal to >=, and less than or equal to <= to conditional statements that use the operator less than <. For conditional statements that originally used the operators greater than or equal to >= and less than or equal to <=, the polarity of the condition state needs to be inverted. Normalize conditional statements in node blocks that use the operator not equal to != to conditional statements that use the operator equal to ==, and invert the polarity of the condition state.

[0043] The normalized conditional statements are used for updating and querying all scenarios during the traversal process. Table 1 shows the normalization logic. In essence, the normalized expression is the conditional expression. It should be noted that the normalization logic in other similar cases is also within the scope of protection of this application.

[0044] Table 1. Normalization Rules

[0045]

[0046] In a single branch, if a certain conditional language appears for the first time, and the list is not dynamically maintained before and no related data is stored, all possible conditional states are obtained for subsequent replication. The record of the conditional state value is used as the basis for subsequent pruning queries.

[0047] The conditional state corresponding to the conditional statement is the Boolean value of the conditional expression. The basic pruning logic is that if BLOCK0 has determined that the conditional state of conditional statement A is false, and the value of the variable in the conditional statement has not been changed or has not caused a change in the conditional state, then BLOCK3 cannot determine that conditional statement A is true. The pruning state does not conform to the processing flow direction of the out-degree edge true.

[0048] In step S140, for the first occurrence of the conditional statement and cases where no pruning has been performed after the query, a copy of the dynamically maintained list is generated. This copy is used for independent updates and queries under subsequent branch condition states, specifically including:

[0049] When a single branch traverses to a certain record cell, if the conditional statement is appearing for the first time or has not been pruned after the query, a new branch is generated based on the out-degree edge of that record cell, and a copy that is completely identical to the original dynamically maintained list is generated. The copy is used as a dynamically maintained list where the conditional states of each branch are independent.

[0050] The above two situations indicate that the out-degree edge has two conditional states: true and false. A new branch is about to be generated. The information recorded in the subsequent execution process will change, but the information recorded before this is exactly the same. Therefore, a completely identical copy is generated for each branch to update independently. Both branches can use the copy. Preferably, one of them can be chosen to continue using the original dynamically maintained list. No pruning is needed after the judgment is not the first time. This may be because the compiler cannot judge or there are other complex situations.

[0051] Since condition judgment units generally only have two out-degree edges, if the out-degree edges need to be pruned, it means that no new branches will be generated for the time being, and there is no need to generate copies to continue updating.

[0052] It should be noted that replicas are only generated for the current single branch without pruning. The code analysis path obtained before this is unique. This replica generation rule does not apply to other branches that have already reached the same unit before this record unit.

[0053] During the traversal, the updated and retrieved stored content is achieved by dynamically maintaining a list. The stored content includes the current traversal path, the values ​​of variables in the conditional statement, and the values ​​of the conditional state. The values ​​of the variables are used to update the values ​​of the conditional state. It should be noted that in this embodiment of the invention, the values ​​of the variables are not limited to numerical values, but can also be descriptions of states or relationships.

[0054] In this embodiment of the invention, a database capable of satisfying adaptive index types is used as the dynamically maintained list, such as Redis, PostgreSQL, and Oracle.

[0055] During the traversal process, a heat index flag is used to control the sorting in the dynamically maintained list. The frequency of the conditional statement being queried in real time is used as the value of the heat index flag. The storage order of the conditional statements is arranged from high to low according to the value of the heat index flag. In this embodiment of the invention, the values ​​of variables and conditional states in the conditional statements are stored in a sub-table. The columns in the sub-table are used to store the conditional expression, the corresponding conditional state, and the value of the corresponding variable in the conditional statement in turn. The conditional expression is similar to the key of the query.

[0056] The traversal path only records the nodes that have been traversed in the current dynamically maintained list. It is not used as a condition for pruning and is stored independently from the content sorted by the popularity flag.

[0057] The method further includes:

[0058] After the traversal is complete, the pruned code analysis path is obtained.

[0059] Method Example 2

[0060] The code for Example 2 is as follows:

[0061] void handleElem(int a, int b) {

[0062] if (a == b) {

[0063] deleteElem();

[0064] } else {

[0065] addElem();

[0066] }

[0067] if (a == b) {

[0068] checkNewElem();

[0069] } else {

[0070] checkNumber();

[0071] }

[0072] }

[0073] Figure 2 This is a schematic diagram of the control flow graph of Embodiment 2 of the present invention, as shown below. Figure 2The diagram shows the Control Flow Graph (CFC) structure. Without path pruning during code analysis, any edge could potentially be executed. The original code analysis path has the following four paths, where B0 is BLOCK0, and the others can be obtained similarly:

[0074] (1) B0 -> B1 -> B3 -> B4

[0075] (2) B0 -> B1 -> B3 -> B5

[0076] (3) B0 -> B2 -> B3 -> B4

[0077] (4) B0 -> B2 -> B3 -> B5

[0078] Figure 3 This is a schematic diagram of the pruning process in Embodiment 2 of the present invention, as shown below. Figure 3 As shown, the pruning process is illustrated. The marker units that need to be tracked are BLOCK0 and BLOCK3. Starting from the entry unit BLOCK0, if (a==b) there are two possible condition states, true and false. At this time, a copy of the dynamic maintenance list is generated, and the two states are recorded in dynamic maintenance list 1 and dynamic maintenance list 2 respectively, resulting in two branches that are executed in parallel.

[0079] In the dynamic maintenance list 1 corresponding to branch 1, record a==b true and other information. After executing BLOCK1, reach BLOCK3. If a==b is true, it is impossible to determine it as false in BLOCK3. In this case, prune the out-degree edge of BLOCK3 that is false. Similarly, for branch 2 and the information in the corresponding dynamic maintenance list 2, prune the out-degree edge of BLOCK3 that is true.

[0080] After conditional pruning, the following two analysis paths are obtained:

[0081] (1) B0->B1->B3->B4

[0082] (2) B0->B2->B3->B5

[0083] Method Example 3

[0084] The code for Example 3 is as follows:

[0085] void testConditon(int a, int b, int c, int d) {

[0086] int p = nullptr;

[0087] int var;

[0088] if (a == b) {

[0089] return;

[0090] }

[0091] var = (a>b&&c <d) ? a : b;

[0092] if (var == a&&a<= b) {

[0093] var = p; / / False positive: dereferencing a null pointer

[0094] }

[0095] return;

[0096] }

[0097] Figure 4 This is a schematic diagram of the control flow graph of Embodiment 3 of the present invention, as shown below. Figure 4 As shown, the Control Flow Graph (CFC) structure is illustrated. Example 3 includes compound conditional statements, which have therefore been split. Without path pruning during code analysis, any edge could potentially be executed, and this is further demonstrated when analyzing `var=`. The line of code p will generate a false positive for null pointer dereference; the original code analysis path has the following 10 paths:

[0098] (1) B0 -> B9

[0099] (2) B0 ->B1 ->B2 ->B4 ->B5 ->B6 ->B7 ->B8

[0100] (3) B0 ->B1 ->B2 ->B4 ->B5 ->B6 ->B8

[0101] (4) B0 ->B1 ->B2 ->B4 ->B5 ->B8

[0102] (5) B0 ->B1 ->B2 ->B3 ->B5 ->B6 ->B7->B8

[0103] (6) B0 ->B1 ->B2 ->B3 ->B5 ->B6 ->B8

[0104] (7) B0 ->B1 ->B2 ->B3 ->B5 ->B8

[0105] (8)B0 -> B1 -> B5 -> B5 -> B6 -> B7 -> B8

[0106] (9)B0 -> B1 -> B3 -> B5 -> B8

[0107] (10)B0 -> B1 -> B3 -> B5 -> B6 -> B8

[0108] Figure 5 is a schematic diagram of the pruning process in the third embodiment of the present invention. As Figure 5 shown, it shows a reference schematic of the pruning process of one of the branches, and can show, for example, the generation process of the final path B0 -> B1 -> B2 -> B4 -> B5 -> B6 -> B8. The marking units that need to be traced are the BLOCKs corresponding to b < a, c < d, var == a, and a == b. When the conditional statement in BLOCK2 appears for the first time during execution, a copy is generated. Record c < d true in the dynamic maintenance list 1 of the left branch and record c < d false in the dynamic maintenance list 2 of the right branch, and then record and update independently;

[0109] After pruning based on the conditions, the following 6 analysis paths are obtained:

[0110] (1)B0 -> B9

[0111] (2)B0 -> B1 -> B2 -> B4 -> B5 -> B6 -> B8

[0112] (3)B0 -> B1 -> B2 -> B4 -> B5 -> B8

[0113] (4)B0 -> B1 -> B2 -> B3 -> B5 -> B6 -> B8

[0114] (5)B0 -> B1 -> B2 -> B3 -> B5 -> B8

[0115] (6)B0 -> B1 -> B3 -> B5 -> B8

[0116] It can be obtained from the third embodiment of the invention that adopting the path pruning method can avoid walking to var = p, and the false positives caused by referencing a null pointer can be eliminated.

[0117] In summary, to address the existing problems, this invention proposes a code analysis path pruning method based on control flow graph path pruning. It explicitly uses conditional state-based pruning logic, omitting invalid paths from analysis, thereby improving code analysis efficiency to support in-depth analysis of more complex code. This effectively solves the problem of pruning being impossible due to the inability to determine the exact value of non-constant values, while also avoiding unnecessary misjudgments during analysis. During control flow graph generation, compound conditional statements are effectively split and normalized during traversal, facilitating logical judgment and query storage. Furthermore, a multi-branch parallel approach is used to traverse the control flow graph to accelerate the coverage of different paths. An independent database is maintained by generating copies when new branches are created, avoiding excessive duplicate data recording while reducing the complexity of thread contention caused by global state storage.

[0118] Device Examples

[0119] According to an embodiment of the present invention, a code analysis path pruning device is provided. Figure 6 This is a schematic diagram of the code analysis path pruning device according to an embodiment of the present invention, as shown below. Figure 6 As shown, the code analysis path pruning device according to an embodiment of the present invention specifically includes:

[0120] The control flow graph generation module 60 is used to extract control flow information from the code to be analyzed, split compound conditional statements, and generate the control flow graph corresponding to the code to be analyzed. In this module, nodes represent execution units or conditional judgment units, and edges represent the path direction of the control flow. Specifically, it is used for:

[0121] Static analysis tools are used to identify the lexical and syntactic structure and control flow logic in the code to be analyzed, and an initial flow graph is generated.

[0122] The AND and OR logic statements in the initial flow graph are split into independent conditional statements, and corresponding condition judgment units are generated to replace the original composite conditional units. All node blocks except the conditional judgment units are used as execution units.

[0123] Tracking marker module 62 is used to mark the condition judgment unit that needs to be tracked as a recording unit, specifically for:

[0124] Within a function or between functions, if the frequency of a conditional statement corresponding to a certain conditional judgment unit is higher than a first preset threshold, or if the frequency of processing of variables in the conditional statement within the execution unit is higher than a second preset threshold, then the corresponding conditional judgment unit is marked as a record unit.

[0125] The traversal pruning module 64 is used to traverse the control flow graph in a multi-branch parallel manner. During the traversal, the conditional statements used are normalized. In a single branch, if the conditional statement of a certain record cell is appearing for the first time, all possible conditional states are maintained; otherwise, the value of the corresponding conditional state is retrieved from the dynamically maintained list. Out-degree edges of record cells that do not match the conditional state are pruned. Specifically, it is used for:

[0126] Normalize the conditional statements in the node block that have the operators greater than, greater than or equal to, and less than or equal to into conditional statements with the operator less than. The original conditional statements with the operators greater than or equal to and less than or equal to need to have their condition polarity reversed.

[0127] Normalize conditional statements in the node block that have the operator "not equal" to conditional statements that have the operator "equal", and invert the polarity of the condition state.

[0128] Normalized conditional statements are used for updates and queries during the traversal process.

[0129] List update module 66 is used to generate a dynamically maintained copy of the list for the first occurrence of a conditional statement and for cases where the query has not been pruned. This copy is then used for independent updates and queries under subsequent branch condition states. Specifically, it is used for:

[0130] When a single branch traverses to a certain record cell, if the conditional statement is appearing for the first time or has not been pruned after the query, a new branch is generated based on the out-degree edge of that record cell, and a copy that is completely identical to the original dynamically maintained list is generated. The copy is used as a dynamically maintained list where the conditional states of each branch are independent.

[0131] During the traversal, the stored content is updated and queried by dynamically maintaining a list. The stored content includes the current traversal path, the values ​​of variables in the conditional statement, and the values ​​of the conditional state.

[0132] During the traversal, a hotness flag is used to control the dynamic maintenance of the list sorting. The frequency of the conditional statement being queried in real time is used as the value of the hotness flag, and the storage order of the conditional statements is arranged from high to low according to the value of the hotness flag.

[0133] The device further includes:

[0134] The path acquisition module 68 is used to obtain the pruned code analysis path after the traversal is completed.

[0135] In summary, to address the existing problems, this invention presents a code analysis path pruning device. It proposes a code analysis method based on control flow graph path pruning, explicitly using conditional state-based pruning logic. Invalid paths are not analyzed, thereby improving code analysis efficiency to support in-depth analysis of more complex code. This effectively solves the problem of pruning being impossible due to the inability to determine the exact value of non-constant values, while also avoiding unnecessary misjudgments during analysis. During control flow graph generation, compound conditional statements are effectively split and normalized during traversal, facilitating logical judgment and query storage. Furthermore, a multi-branch parallel approach is used to traverse the control flow graph to accelerate the coverage of different paths. An independent database is maintained by generating copies when new branches are created, avoiding excessive duplicate data recording while reducing the complexity of thread contention caused by global state storage.

[0136] Electronic device examples

[0137] Figure 7 This is a schematic diagram of an electronic device according to an embodiment of the present invention. The electronic device 700 may include at least one processor 710 and a memory 720. The processor 710 can execute instructions stored in the memory 720. The processor 710 is communicatively connected to the memory 720 via a data bus. In addition to the memory 720, the processor 710 can also be communicatively connected to an input device 730, an output device 740, and a communication device 750 via the data bus.

[0138] The processor 710 can be any conventional processor, such as a commercially available CPU. The processor may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems on chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0139] The memory 720 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0140] In this embodiment of the present disclosure, the memory 720 stores executable instructions, and the processor 710 can read the executable instructions from the memory 720 and execute the instructions to implement all or part of the steps of any of the code analysis path pruning methods in the above exemplary embodiments.

[0141] Computer-readable storage medium embodiments

[0142] In addition to the methods and apparatus described above, exemplary embodiments of this disclosure may also be a computer program product or a computer-readable storage medium storing the computer program product, wherein the computer program product includes computer program instructions that can be executed by a processor to implement all or part of the steps described in any of the code analysis path pruning methods in the exemplary embodiments described above.

[0143] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. Programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages, and scripting languages ​​(e.g., Python). The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0144] Computer-readable storage media may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: static random access memory (SRAM) having one or more electrically connected wires; electrically erasable programmable read-only memory (EEPROM); erasable programmable read-only memory (EPROM); programmable read-only memory (PROM); read-only memory (ROM); magnetic storage; flash memory; magnetic disk or optical disk; or any suitable combination thereof.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A code analysis path pruning method, characterized in that, include: Extract control flow information from the code to be analyzed and split compound conditional statements to generate a control flow graph corresponding to the code to be analyzed. In the control flow graph, the node blocks represent execution units or condition judgment units, and the edges represent the path direction of the control flow. Mark the condition judgment unit that needs to be tracked as a recording unit; The control flow graph is traversed using a multi-branch parallel approach. During the traversal, conditional statements are normalized. In a single branch, if a conditional statement for a record unit is encountered for the first time, all possible conditional states are maintained, including true and false states. Otherwise, the value of the corresponding conditional state is retrieved from the dynamically maintained list, and out-degree edges of record units that do not match the conditional state are pruned. Specifically, this includes: Conditional statements in node blocks with operators greater than >, greater than or equal to >=, and less than or equal to <= are normalized to conditional statements with operator less than <. For the original conditional statements with operators greater than or equal to >= and less than or equal to <=, the polarity of the condition state is inverted. Conditional statements in node blocks with operator not equal to != are normalized to conditional statements with operator equal to ==, and the polarity of the condition state is inverted. The normalized conditional statements are used for updates and queries during the traversal process. For the first occurrence of a conditional statement and cases where no pruning has been performed after a query, a copy of the dynamically maintained list is generated, and this copy is used for independent updates and queries under subsequent branch condition states.

2. The method according to claim 1, characterized in that, The method further includes: After the traversal is complete, the pruned code analysis path is obtained.

3. The method according to claim 1, characterized in that, The step of extracting control flow information from the code to be analyzed and splitting compound conditional statements to generate the control flow graph corresponding to the code to be analyzed specifically includes: Static analysis tools are used to identify the lexical and syntactic structure and control flow logic in the code to be analyzed, and an initial flow graph is generated. The AND and OR logic statements in the initial flow graph are split into independent conditional statements, and corresponding condition judgment units are generated to replace the original composite conditional units. All node blocks except the condition judgment units are used as the execution units.

4. The method according to claim 1, characterized in that, The step of marking the condition judgment unit that needs to be tracked as a recording unit specifically includes: Within a function and within a function, if the frequency of a conditional statement corresponding to a certain conditional judgment unit is higher than a first preset threshold, or the frequency of processing of variables in the conditional statement within the execution unit is higher than a second preset threshold, then the corresponding conditional judgment unit is marked as the recording unit.

5. The method according to claim 1, characterized in that, The step of generating a copy of the dynamically maintained list for the first occurrence of a conditional statement and for cases where no pruning has been performed after a query, and using this copy for independent updates and queries under subsequent branch condition states, specifically includes: When a single branch traverses to a certain record unit, if the condition statement is appearing for the first time or has not been pruned after the query, a new branch is generated based on the out-degree edge of the record unit, and a copy that is completely consistent with the original dynamic maintenance list is generated. The copy is used as a dynamic maintenance list where the condition states of each branch are independent. During the traversal, the stored content is updated and queried through the dynamically maintained list, wherein the stored content includes the current traversal path, the values ​​of variables in the conditional statement, and the values ​​of the conditional state; During the traversal, a popularity flag is used to control the sorting in the list. The frequency of the conditional statement being queried is counted in real time and used as the value of the popularity flag. The storage order of the conditional statements is arranged from high to low according to the value of the popularity flag.

6. A code analysis path pruning device, characterized in that, include: The control flow graph generation module is used to extract control flow information of the code to be analyzed and split compound conditional statements to generate the control flow graph corresponding to the code to be analyzed. The node blocks of the control flow graph represent execution units or condition judgment units, and the edges represent the path direction of the control flow. The tracking marker module is used to mark the condition judgment units that need to be tracked as recording units; The traversal and pruning module is used to traverse the control flow graph in a multi-branch parallel manner. During the traversal, conditional statements are normalized. In a single branch, if the conditional statement of a certain record unit is appearing for the first time, all possible conditional states are maintained, including true and false. Otherwise, the value of the corresponding conditional state is retrieved from the dynamically maintained list, and out-degree edges of record units that do not match the conditional state are pruned. Specifically, it is used for: Normalize conditional statements in node blocks that use the operators greater than >, greater than or equal to >=, and less than or equal to <= to conditional statements that use the operator less than <. For the original conditional statements using the operators greater than or equal to >= and less than or equal to <=, the polarity of the condition state needs to be inverted. Normalize conditional statements in node blocks that use the operator not equal to != to conditional statements that use the operator equal to ==, and invert the polarity of the condition state. Use the normalized conditional statements for updates and queries during the traversal process. The list update module is used to generate a copy of the dynamically maintained list for the first occurrence of a conditional statement and for cases where no pruning has been performed after a query. This copy is then used for independent updates and queries under subsequent branch condition states.

7. The apparatus according to claim 6, characterized in that, The device further includes: The path retrieval module is used to obtain the pruned code analysis path after traversal.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the code analysis path pruning method as described in any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an implementation program for information transmission, which, when executed by a processor, implements the steps of the code analysis path pruning method as described in any one of claims 1 to 5.

Images