File inspection method, electronic device, storage medium and chip system

Abstract

The file inspection method, electronic device, storage medium and chip system provided by the embodiments of the present application relate to the field of terminal technology. The method includes: providing a code static inspection framework based on a cross-file call forest CFCF data structure. The code static inspection framework is a non-compilation-dependent inspection framework that does not require code compilation or compilation parameters. The CFCF data structure can represent the calling relationship between functions in the source code. Based on the CFCF data structure, a code static inspection algorithm can be constructed to support cross-file source code file analysis, that is, it can analyze the function call relationship between multiple source code files, thereby extracting more comprehensive code semantic information, reducing the situation of code defect omissions, and improving the stability and performance of electronic equipment operation.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a file checking method, an electronic device, a storage medium and a chip system. Background Art

[0002] Code defects can affect the stability of software operation, which may cause problems such as black screen and crash on electronic devices. Code defects can also affect the performance of electronic devices, which may cause the electronic devices to have higher power consumption, occupy more memory space, and have longer response time, thereby affecting the user experience.

[0003] In some implementations, electronic devices can perform static checking on codes to reduce code defects. However, some code static checking methods are difficult to extract semantic information of codes, which makes it difficult to perform complex cross-file code analysis and may miss code defects. Summary of the invention

[0004] The file checking method, electronic device, storage medium and chip system provided by the embodiments of the present application provide a code static checking framework based on the cross-file call forest CFCF data structure. The CFCF data structure can represent the calling relationship between functions in the source code, and a code static checking algorithm can be constructed based on the CFCF data structure to support cross-file source code file analysis, thereby extracting more comprehensive code semantic information, reducing the situation of code defect omissions, and improving the stability and performance of electronic equipment operation.

[0005] In a first aspect, an embodiment of the present application provides a file checking method, which is applied to an electronic device, and the method includes:

[0006] Based on M files, a first data structure is obtained, and the first data structure is used to reflect the calling relationship between the N functions included in the M files, where M and N are both integers greater than 0; the first data structure is checked to obtain the inspection results of the M files. In this way, a code static inspection algorithm can be constructed based on the first data structure to support cross-file source code file analysis, that is, the function calling relationship between multiple source code files can be analyzed. In addition, more comprehensive code semantic information can be extracted, the situation of code defect omissions can be reduced, and the stability and performance of electronic equipment operation can be improved.

[0007] In a possible implementation, the first data structure is a tree structure, and the first data structure includes a first set and a second set, the first set is a leaf set of the tree structure, the second set is a vertex set of the tree structure, the first set includes N functions and the calling relationships of the N functions, and the second set includes N functions. In this way, the tree structure can better represent the calling hierarchy relationship between data, accurately represent complex function relationships, and can quickly search and traverse any leaf in the tree. Therefore, code defect inspection can be performed efficiently and flexibly based on the first data structure.

[0008] In a possible implementation, the first data structure CFCF satisfies the following relationship:

[0009] CFCF = (CC, I).

[0010] Among them, CC represents the first set, and I represents the second set. In this way, a relatively complete tree-structured cross-file call forest CFCF can be constructed through the first set and the second set, so that in cross-file code analysis, code semantic information can be more comprehensively represented.

[0011] In a possible implementation, the N functions include a target function, the first set includes the target function and L call relations related to the target function, L is an integer greater than 0, and any call relation cc of the L call relations satisfies the following relationship:

[0012] cc = (depth, succ, preds, callsite).

[0013] Among them, depth represents the function call depth of any call relation, succ represents the third set, preds represents the fourth set, and callsite represents the relevant information of any call relation; the third set includes other call relations among the L call relations called by any call relation, and the fourth set includes other call relations among the L call relations that call any call relation. In this way, according to the relationship satisfied by any call relation cc, the file to be analyzed can be analyzed, the call point of calling the key API function can be iteratively found, and a direct or indirect call chain can be constructed.

[0014] In one possible implementation, the function call depth is less than or equal to a preset value. If the function call depth is greater than the preset value, that is, the length of the call chain is too long, it may affect the accuracy of code analysis and make the code analysis time longer, affecting the efficiency of code analysis. Therefore, the embodiment of the present application also sets a maximum call chain length l max, which is used to limit the depth of function calls, so that the call chain will not be too long, thereby improving the accuracy of code analysis, reasonably controlling the duration of code analysis, and improving the efficiency of code analysis.

[0015] In a possible implementation, the callsite related information of any call relationship satisfies the following relationship:

[0016] callsite = (Caller, File, Controls, Caller_line, Callee, Call_line).

[0017] Among them, Caller represents the signature of the calling function, File represents the file where the calling function is located, Controls represents the control flow relationship, Caller_line represents the position of the calling function in the file, Callee represents the signature of the called function, and Call_line represents the position of the called function in the file; the signature of the calling function includes the combination of the name of the calling function and the number of parameters; the signature of the called function includes the combination of the name of the called function and the number of parameters; the control flow relationship includes one or more of the following control flow relationships: the control flow relationship related to the for loop, the control flow relationship related to the if conditional statement, the control flow relationship related to the while loop, the control flow relationship related to the do loop, and the control flow relationship related to the switch selection statement. In this way, Callsite can record the relevant information related to any calling relationship cc in more detail, including the calling function, the called function, the number of code lines corresponding to the calling function, the number of code lines corresponding to the called function, etc., which is conducive to the analysis of code defects.

[0018] In a possible implementation, the control flow relation Controls satisfies the following relationship:

[0019] Controls = {"FOR_BODY", "FOR_CONDITION", "FOR_INITIALIZER", "FOR_ITERATION", "IF_CONDITION","IF_ELSE","IF_THEN","WHILE_BODY","WHILE_CONDITION","DO_BODY","DO_CONDITION","SWITCH_CONDITION","SWITCH_CASE","SWITCH_DEFAULT"};

[0020] Among them, FOR_BODY represents the loop body in the for loop, FOR_CONDITION represents the conditional statement in the for loop, FOR_INITIALIZER represents the initialization statement in the for loop, FOR_ITERATION represents the iteration statement in the for loop, IF_CONDITION represents the conditional statement in the if conditional statement, IF_ELSE represents the else execution body in the if conditional statement, IF_THEN represents the if execution body in the if conditional statement, WHILE_BODY represents the loop body in the while loop, WHILE_CONDITION represents the conditional statement in the while loop, DO_BODY represents the loop body in the do loop, DO_CONDITION represents the conditional statement in the do loop, SWITCH_CONDITION represents the conditional statement in the switch selection statement, SWITCH_CASE represents the case execution body in the switch selection statement, and SWITCH_DEFAULT represents the default execution body in the switch selection statement. Splitting the above programming statements can more detailedly represent the calling relationship between functions and extract more comprehensive code semantic information.

[0021] In a possible implementation, the inspection results include the results related to code defects found in M ​​files, and the code defects include one or more of the following: performance defects, syntax defects, variable and scope defects, control flow defects, function and method defects, memory management defects, and code naming standard defects. In this way, developers can modify the code based on the inspection results to obtain higher quality code and make the software run more stably.

[0022] In a possible implementation, a first data structure is obtained based on M files, including: performing lexical analysis and syntax analysis on the codes in the M files to obtain an abstract syntax tree set ASTs; looping through the first function node in ASTs to find out whether the first function node has a parent node, wherein the function signature of the first function node is in the calling function signature of the first set; if the first function node has a parent node, then adding the function corresponding to the parent node to the first set of the first data structure, and updating the first function node to the parent node, and continuing to traverse the first function node in ASTs; if the first function node does not have a parent node, then ending the traversal of ASTs; and outputting the first data structure. In this way, an algorithm is constructed based on the first data structure to achieve automatic analysis of source code files. By iteratively searching for call points that call key API functions, direct or indirect call chains are constructed, so that cross-file defect inspection of the code can be performed, and a defect inspection report is finally output.

[0023] In one possible implementation, a second data structure is also stored in the electronic device, the second data structure is the first data structure obtained last time, the function signature of the first function node is in the calling function signature of the first set, and the first set includes the calling relationship related to the first function in the second data structure. Through the historical CFCF library, the function calling relationship obtained by the previous analysis can be obtained. In this way, for the function calling relationship already in the file, the electronic device does not need to analyze it again, reducing computing power, so that the first data result can be obtained faster, and the code inspection efficiency is improved.

[0024] In a possible implementation, before checking the first data structure, the method further includes: obtaining configuration information in a configuration file and / or a check item registry; checking the first data structure to obtain check results for M files, including: checking the first data structure based on the configuration information to obtain check results for M files. Users or developers can configure and modify check items in the configuration file, so that users or developers can conveniently and flexibly check code defects by modifying the configuration file, reduce code modifications, and facilitate function implementation and maintenance.

[0025] In one possible implementation, the check item registry includes one or more of the following check items: performance defect check items, syntax check items, variable and scope check items, control flow check items, function and method check items, memory management check items, and code naming specification check items; the configuration file includes check items that are closed in the check items, check items that are enabled in the check items, and / or N functions for constructing the first data structure. According to the check items, the code in M ​​files can be checked for defects, so that developers can discover and modify defects in the code in advance and make modifications. Thereby improving the robustness of the code, allowing electronic devices running the code to run stably, and reducing the occurrence of black screens, flashbacks, etc. in electronic devices.

[0026] In a second aspect, an embodiment of the present application provides a device for file inspection, which may be an electronic device, or a chip or chip system in an electronic device. The device may include a processing unit. The processing unit is used to implement any method related to processing performed by the electronic device in the first aspect or any possible implementation of the first aspect. When the device is an electronic device, the processing unit may be a processor. The device may also include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit so that the electronic device implements a method described in the first aspect or any possible implementation of the first aspect. When the device is a chip or chip system in an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit so that the electronic device implements a method described in the first aspect or any possible implementation of the first aspect. The storage unit may be a storage unit in the chip (for example, a register, a cache, etc.), or a storage unit in the electronic device located outside the chip (for example, a read-only memory, a random access memory, etc.).

[0027] In a third aspect, an embodiment of the present application provides an electronic device, comprising one or more processors and a memory, wherein the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors are used to call computer instructions to execute the method described in the first aspect or any possible implementation of the first aspect.

[0028] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program or instructions are stored. When the computer program or instructions are run on a computer, the computer executes the method described in the first aspect or any possible implementation of the first aspect.

[0029] In a fifth aspect, an embodiment of the present application provides a computer program product including a computer program. When the computer program runs on a computer, the computer executes the method described in the first aspect or any possible implementation manner of the first aspect.

[0030] In a sixth aspect, the present application provides a chip or a chip system, the chip or chip system comprising at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and the at least one processor is used to run a computer program or instruction to execute the method described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input / output interface, a pin or a circuit, etc.

[0031] In a possible implementation, the chip or chip system described above in the present application further includes at least one memory, in which instructions are stored. The memory may be a storage unit inside the chip, such as a register, a cache, etc., or a storage unit of the chip (such as a read-only memory, a random access memory, etc.).

[0032] It should be understood that the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0034] Figure 2 A schematic diagram of the software structure of an electronic device provided in an embodiment of the present application;

[0035] Figure 3 A schematic diagram of function calls between source codes in multiple files provided in an embodiment of the present application;

[0036] Figure 4 A schematic diagram of a representation method of a call chain cc provided in an embodiment of the present application;

[0037] Figure 5 A schematic diagram of a code static checking framework based on CFCF provided in an embodiment of the present application;

[0038] Figure 6 A schematic diagram of a file checking method provided in an embodiment of the present application;

[0039] Figure 7 A schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] In order to clearly describe the technical solutions of the embodiments of the present application, some terms and technologies involved in the embodiments of the present application are briefly introduced below:

[0041] 1. Terminology

[0042] In the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same functions and effects. For example, the first chip and the second chip are only used to distinguish different chips, and their order is not limited. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0043] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0044] In the embodiments of the present application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple.

[0045] 2. Electronic equipment

[0046] The electronic device of the embodiment of the present application may also be a terminal device in any form. For example, the electronic device may include: a mobile phone, a tablet computer, a PDA, a laptop computer, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, a vehicle-mounted device, a wearable device, an electronic device in a 5G network or a public land mobile communication network (public land mobile communication network) to be evolved in the future. The electronic devices in the mobile network (PLMN) are not limited to this in the embodiments of the present application.

[0047] As an example but not limitation, in the embodiments of the present application, the electronic device may also be a wearable device. Wearable devices may also be referred to as wearable smart devices, which are a general term for wearable devices that are intelligently designed and developed using wearable technology for daily wear, such as glasses, gloves, watches, clothing, and shoes. A wearable device is a portable device that is worn directly on the body or integrated into the user's clothes or accessories. Wearable devices are not only hardware devices, but also powerful functions achieved through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include full-featured, large-sized, and fully or partially independent of smartphones, such as smart watches or smart glasses, as well as devices that only focus on a certain type of application function and need to be used in conjunction with other devices such as smartphones, such as various types of smart bracelets and smart jewelry for vital sign monitoring.

[0048] In addition, in the embodiments of the present application, the electronic device may also be an electronic device in an Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network that interconnects people and machines and things.

[0049] The electronic device in the embodiments of the present application may also be referred to as: user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, etc.

[0050] In an embodiment of the present application, the electronic device or each network device includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and a memory (also called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a Windows operating system. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0051] For example, Figure 1 A schematic diagram of the structure of a terminal device is shown.

[0052] The terminal device may include a processor 110 , an external memory interface 120 , an internal memory 121 , a universal serial bus (USB) interface 130 , a charging management module 140 , a power management module 141 , a battery 142 , a wireless communication module 150 , and a display screen 160 .

[0053] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the terminal device. In other embodiments of the present application, the terminal device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The components shown in the figure may be implemented by hardware, software, or a combination of software and hardware.

[0054] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). Among them, different processing units may be independent devices or integrated into one or more processors. The controller may be the nerve center and command center of the terminal device. The controller may generate an operation control signal according to the instruction opcode and the timing signal to complete the control of fetching and executing instructions.

[0055] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0056] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the terminal device. In other embodiments of the present application, the terminal device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0057] The internal memory 121 can be used to store computer executable program codes, and the executable program codes include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the terminal device (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the terminal device by running instructions stored in the internal memory 121 and / or instructions stored in a memory provided in the processor. For example, in an embodiment of the present application, the processor may enable the terminal device to execute the power consumption control method provided in an embodiment of the present application by running instructions stored in the internal memory.

[0058] The software system of the electronic device may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention takes a Windows system with a layered architecture as an example to exemplify the software structure of the electronic device.

[0059] Figure 2 It is a software structure block diagram of the electronic device according to an embodiment of the present application.

[0060] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Windows system is divided into user state and kernel state.

[0061] The user state can be understood as the environment in which the application runs. The application can access its own memory space and limited system resources, and can also execute non-privileged instructions; the user state can also be understood as the tasks performed by the application. The user state can include the application layer and the subsystem dynamic link library.

[0062] Kernel state can be understood as the environment in which the operating system runs. The operating system can access all resources and execute privileged and non-privileged instructions. Privileged instructions can be understood as instructions executed in kernel state, which can access and modify the system's hardware resources and memory; kernel state can be understood as the tasks performed by the operating system. Kernel state can be divided from top to bottom into executive body, kernel and device driver, and hardware abstraction layer (HAL).

[0063] like Figure 2As shown in the figure, the application layer includes office, browser, social, music, video, game and other applications. Applications can include system applications and third-party applications. The application layer can also include an environment subsystem, which can display certain subsets of basic execution system services to applications in a specific form to provide an execution environment for applications.

[0064] The subsystem dynamic link library may include an application programming interface (API) module, which includes Windows API, Windows native API, etc. Among them, both Windows API and Windows native API can provide system call entry and internal function support for applications. The difference is that Windows native API is an API native to the Windows system. For example, Windows API may include user.dll and kernel.dll, and Windows native API may include ntdll.dll. Among them, user.dll is the Windows user interface interface, which can be used to perform operations such as creating windows and sending messages. Kernel.dll is used to provide applications with an interface to access the kernel. ntdll.dll is an important Windows NT kernel-level file. When Windows starts, ntdll.dll resides in a specific write-protected area in the memory, so that other programs cannot occupy this memory area.

[0065] The executive body may include a process manager, a virtual memory manager, an I / O manager, a power manager, an operating system event driver (OsEventDriver) node, and the like.

[0066] The process manager is used to create and terminate processes and threads.

[0067] The Virtual Memory Manager implements "virtual memory". The Virtual Memory Manager also provides basic support for the Cache Manager.

[0068] The I / O manager performs device-independent input / output and further processes calls appropriate device drivers.

[0069] The power manager manages power state changes for all devices that support power state changes.

[0070] The system event driven node can interact with the kernel and driver layer, for example, interact with the graphics card driver, and after determining that there is a GPU video decoding event, report the GPU video decoding event to the scene recognition engine.

[0071] The kernel and driver layer includes the kernel and device drivers.

[0072] The kernel is an abstraction of the processor architecture, isolating the executive body from the differences in the processor architecture to ensure the portability of the system. The kernel can perform thread scheduling and control, trap processing and exception management, interrupt processing, etc.

[0073] Device drivers run in kernel mode and are interfaces between the I / O system and related hardware. Device drivers may include graphics card drivers, audio drivers, video drivers, camera drivers, keyboard drivers, etc.

[0074] HAL is a kernel-state module that can hide various hardware-related details, such as I / O interfaces, interrupt controllers, and multi-processor communication mechanisms, and provide a unified service interface for different hardware platforms running Windows, achieving portability on multiple hardware platforms. It should be noted that in order to maintain the portability of Windows, Windows internal components and user-written device drivers do not directly access the hardware, but call routines in HAL.

[0075] It should be noted that the embodiments of the present application are only illustrated using the Windows system as an example. In other operating systems (such as the Android system, the IOS system, etc.), as long as the functions implemented by each functional module are similar to those in the embodiments of the present application, the solutions of the present application can also be implemented.

[0076] Code defects can affect the stability of software operation, which may cause problems such as black screen and crash on electronic devices. Code defects can also affect the performance of electronic devices, which may cause the electronic devices to have higher power consumption, occupy more memory space, and have longer response time, thereby affecting the user experience.

[0077] In some implementations, electronic devices can perform static checks on the code to reduce code defects. Code static checking can be understood as the ability to statically check potential risks in the code by matching code defect patterns without dynamically running the software, thereby preventing code defects in advance and improving software quality. It is understandable that some common errors in the program or code defects that cause program exceptions may have the same causes and / or the same representations. The same defect pattern can be extracted according to the laws of occurrence of these code defects, and this defect pattern can be called a code defect pattern.

[0078] Exemplarily, code defect patterns may include time-consuming operations in for loops, time-consuming operations in user interface (UI) threads, resource leaks, etc. Among them, time-consuming operations may include operations of printing logs, sending hypertext transfer protocol (HTTP) requests, regular expression parsing, etc. For example, if time-consuming operations are performed in a for loop or UI thread, it may affect the performance of the electronic device, causing the electronic device to freeze and other problems. If the resources in the electronic device are only applied for but not released, it may occupy more memory space of the electronic device and reduce the performance of the electronic device.

[0079] Code static checking can include compile-dependent checking and non-compile-dependent checking.

[0080] Compilation dependency checking takes compilation parameters as input, and requires code compilation based on the compilation information in the entire software engineering build process. Compilation dependency checking can extract semantic information of the code, such as semantic information including parameters and return value types of function calls, perform semantic analysis, and achieve more accurate static checking. However, compilation dependency checking requires software engineering to be built in advance. If the software engineering build fails, some files cannot be analyzed, and the entire software engineering build process takes a long time. Compilation dependency checking also requires compilation parameters of source files as input, which limits its usage scenarios.

[0081] Non-compile dependency checking does not require code compilation or compilation parameters, is time-saving, and has a wide range of usage scenarios. However, it is difficult for non-compile dependency checking to extract semantic information from the code, making it difficult to perform complex cross-file code analysis and causing the problem of missing code defects.

[0082] The compilation parameters may represent command line parameters passed to the compiler, which are used to control various behaviors of the compilation process. For example, the compilation parameters may include compilation dependencies, header files, etc. In some scenarios, the compilation parameters may also be called compilation options.

[0083] In view of this, the file checking method of the embodiment of the present application provides a code static checking framework based on the cross file call forest (CFCF) data structure. The code static checking framework is a non-compilation-dependent checking framework that does not require code compilation or compilation parameters. The CFCF data structure can represent the calling relationship between functions in the source code. Based on the CFCF data structure, a code static checking algorithm can be constructed to support cross-file source code file analysis, that is, it can analyze the function call relationship between multiple source code files, thereby extracting more comprehensive code semantic information, reducing the situation of code defect omissions, and improving the stability and performance of electronic equipment operation.

[0084] Wherein, source code can also be referred to as source code, which means a computer program code written in a programming language and not compiled or interpreted. Source code can be written in a variety of programming languages, such as C, C++, Java, Python, JavaScript, etc., which are not limited in the embodiments of the present application. For ease of description, the embodiments of the present application are described later using C family codes as an example, wherein C family codes may include C code and C++ code.

[0085] It is understood that in programming, a macro can represent a preprocessor directive that defines a shorthand for a code snippet or expression. For example, in C or C++, a macro can be defined by a "#define" directive. Macro expansion can mean that during the compilation process, the preprocessor replaces the macro with the actual code it defines. Macro expansion is usually performed in the preprocessing stage.

[0086] The following specific embodiments are used to describe the method of the present application in detail. The following embodiments may be combined with each other or implemented independently, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0087] In the embodiment of the present application, the cross-file call forest CFCF may be a tuple, and CFCF may be expressed as CFCF = (CC, I). CC may be the leaf set of the forest, representing the set of function call chains (call chain, cc); I may be the vertex set of the forest, representing the starting API set, and the vertex set I of the forest belongs to the leaf set CC of the forest, that is, I CC,I can also be called key API set or key interface set.

[0088] The key API set can be pre-set by the electronic device or set by the user according to actual needs. For example, the interface for printing logs can be used as the key API set, which is not limited in the embodiments of the present application.

[0089] The call chain cc can represent the calling relationship between two or more functions during the execution of the program. For example, function a calls function b, function b calls function c, and so on. Functions can be chained to form a calling relationship between functions.

[0090] In the embodiment of the present application, the call chain cc can be represented by a four-tuple, and the call chain cc can be represented as cc = (depth, succ, preds, callsite).

[0091] depth indicates the depth of the call chain. succ indicates the subsequent call chain, which can also be understood as the call chain called by cc. The subsequent call chain is also in the leaf set of the forest, that is, succ CC. preds represents the predecessor call chain, which can also be understood as the call chain that calls cc. The predecessor call chain is also in the leaf set of the forest, that is, preds CC. callsite represents the call site in cc, callsite = (Caller, File, Controls, Caller_line,Callee, Call_line).

[0092] Among them, Caller represents the signature of the calling function; the signature of the calling function Caller can be expressed as "function name (number of parameters)", for example: the signature of the function method5(bool par1, bool par2) is method5(2), and the "2" in the signature means that the number of parameters is equal to 2. The signature of the function method5(bool par1, bool par2, ...) is method5(2...), and the "2..." in the signature means that the number of parameters is greater than or equal to 2.

[0093] File represents the file where the calling point is located, which can also be understood as the file where the calling function is located.

[0094] Caller_line indicates the calling function declaration location, which can also be understood as the number of code lines corresponding to the calling function declaration location in the code.

[0095] Callee represents the signature of the called function. The representation of the called function signature Callee is the same as that of the calling function signature Caller, which will not be repeated here.

[0096] Call_line indicates the location of the call point, which indicates the location of the called function. It can also be understood as the number of lines of code corresponding to the location of the called function in the code. Call_line can also be called the location of the call point or the location of the called function.

[0097] Controls represents the control flow relationship; the control flow relationship Controls includes:

[0098] Controls = {"FOR_BODY", "FOR_CONDITION", "FOR_INITIALIZER", "FOR_ITERATION", "IF_CONDITION","IF_ELSE","IF_THEN","WHILE_BODY","WHILE_CONDITION","DO_BODY","DO_CONDITION","SWITCH_CONDITION","SWITCH_CASE","SWITCH_DEFAULT"}.

[0099] Exemplarily, taking the for loop "for (i = 0; i < n; i++){body1;}" as an example, since the variable i in the for loop can be executed multiple times, when the called function is used for iterative calculation as the variable i, the called function can be called multiple times. Therefore, the for loop can be split to more detailedly represent the call relationship between functions. Specifically, FOR_BODY can represent the loop body in the for loop, such as "body1" in the example, FOR_CONDITION can represent the conditional statement in the for loop, such as "i < n" in the example, FOR_INITIALIZER can represent the initialization statement in the for loop, such as "i = 0" in the example, and FOR_ITERATION can represent the iterative statement in the for loop, such as "i++" in the example.

[0100] Taking the conditional statement "if (condition1){body2;}else{body3;}" as an example, since the called function can be executed in the if condition condition1, the if execution body body2, and / or the else execution body body3 of the conditional statement, the conditional statement can be split to more detailedly represent the call relationship between functions. Specifically, IF_CONDITION can represent the if condition in the conditional statement, such as "condition1" in the example, IF_THEN can represent the if execution body in the conditional statement, such as "body2" in the example, and IF_ELSE can represent the else execution body in the conditional statement, such as "body3" in the example.

[0101] Take the while loop "while (condition2){body4;}" as an example. Since the called function can be executed in the condition condition2 and / or the loop body body4 of the while loop, the while loop can be split to more specifically represent the calling relationship between functions. Specifically, WHILE_BODY can represent the loop body in the while loop, such as "body4" in the example, and WHILE_CONDITION can represent the condition in the while loop, such as "condition2" in the example.

[0102] Take the do loop "do{body5;} while (condition3);" as an example. Since the called function can be executed in the loop body5 and / or condition3 of the do loop, the do loop can be split to more specifically represent the calling relationship between functions. Specifically, DO_BODY can represent the loop body in the do loop, such as "body5" in the example, and DO_CONDITION can represent the condition in the do loop, such as "condition3" in the example.

[0103] Take the switch conditional statement "switch(condition4){case:body6; break; default:body7;}" as an example. Since the called function can be executed in the switch statement's condition condition4, case execution body body6, and / or default execution body body7, the switch statement can be split to more specifically represent the calling relationship between functions. Specifically, SWITCH_CONDITION can represent the condition in the switch statement, such as "condition4" in the example, SWITCH_CASE can represent the case execution body in the switch statement, such as "body6" in the example, and SWITCH_DEFAULT can represent the default execution body in the switch statement, such as "body7" in the example.

[0104] It can be understood that if a call chain cc does not include any control flow relationship or control statement, the controls of the call chain cc can be set to empty. For example, empty can be represented by "[ ]".

[0105] Figure 3 A schematic diagram of function calls between source codes in multiple files is shown.

[0106] It is known that the key API set I = {“method0(…) ”}, and the source code file set File = {“Ac”, “Bc”, “Cc”}.

[0107] File Ac contains two call chains related to key APIs:

[0108] The first call chain (cc1): The function macro method1(f, ...) defined in line 19 calls the key API method0("<%s>:", f) in line 19. "<%s>:" can represent the formatting of a string. The function method1(f, ...) is the calling function, the call chain depth is 1, and its calling function signature is caller = method1(1...), caller∈Caller.

[0109] It is understandable that a functional macro is a form of macro. In programming languages, functional macros are defined using the "#define" directive, which is similar to a function call in appearance and use. Functional macros can accept parameters and replace these parameters into the macro body during the preprocessing phase, thereby achieving an effect similar to a function call. Functional macro definition can be understood as the process and syntax for defining functional macros. For example, taking #define SQUARE(x) ((x) * (x)) as an example, "SQUARE" represents a functional macro, "#define SQUARE(x) ((x) * (x))" represents a functional macro definition, x is a parameter, and "((x) * (x))" represents the macro body. In some scenarios, functional macros and functional macro definitions can also be understood as the same concept.

[0110] The second call chain (cc2): The function method5(bool part1, bool part2,...) defined on line 24 indirectly calls the key API method0("<%s>:",f) on line 19 through the function method1(VAR1) on line 26. Among them, the function method5(bool part1, bool part2, ...) is the calling function, the call chain depth is 2, and its calling function signature is caller = method5(2...), caller∈Caller.

[0111] File Bc contains two call chains related to key APIs:

[0112] The third call chain (cc3): The function method6() defined in line 9 calls the key API method0("<%s>:", VAR2) in line 12. Among them, function method6() is the calling function, the call chain depth is 1, and its calling function signature is caller = method6(0), caller∈Caller.

[0113] The fourth call chain (cc4): The function method7() defined in line 15 indirectly calls the key API method0(“<%s>:”, VAR2) through the function methd6() in line 18. Among them, function method7() is the calling function, the call chain depth is 2, and its calling function signature is caller = method7(0), caller∈Caller.

[0114] The file Cc contains two call chains related to key APIs:

[0115] The fifth call chain (cc5): The function method8(struct Type2 *argue, boolarg2, bool arg3) defined on line 45 indirectly calls the function method5(bool part1, bool part2, ...) on line 24 in the file "Ac" by calling the function method5(true, true) on line 53. The function method5(bool part1,bool part2, ...) in turn calls the key API method0("<%s>:", f) on line 19. Among them, the function method8(struct Type2 *argue, bool arg2, bool arg3) is the calling function, the call chain depth is 3, and its calling function signature is caller = method8(3), caller∈Caller, and its control flow control = ["IF_THEN"], control∈Controls.

[0116] The sixth call chain (cc6): The function method8(struct Type2 *argue, boolarg2, bool arg3) defined on line 45 indirectly calls the function method5(bool part1, bool part2, ...) on line 24 in the file "Ac" through the function method5(true, false) on line 59. The function method5(bool part1, boolpart2, ...) in turn calls the key API method0("<%s>:", f) on line 19. Among them, the function method8(struct Type2 *argue, bool arg2, bool arg3) is the calling function, the call chain depth is 3, its calling function signature is caller = method8(3), caller∈Caller, its control flow control = ["FOR_BODY", "IF_THEN"], control∈Controls.

[0117] According to the above analysis, we can also know that cc1, cc2, cc3 and cc4 belong to intra-file function calls, and cc5 and cc6 involve cross-file function calls.

[0118] Figure 4 A schematic diagram showing the representation of the call chain cc in CFCF is shown.

[0119] right Figure 3 By analyzing the source code files in , we can generate a cross-file call forest cfcf = (CC, I), where the call chain set CC = {i1, cc1, cc2, cc3, cc4, cc5, cc6} and the key API set I = {i1}. Figure 4 As shown in b, each node in the graph can represent a function call point with the call chain as the context, and the edge represents the function call relationship. cc1 to cc2, and cc3 to cc4 belong to intra-file function calls, and cc2 to cc5, and cc2 to cc6 belong to cross-file function calls.

[0120] exist Figure 4 In a, the contents of the second call chain cc2 are shown in detail.

[0121] according to Figure 3From the analysis of the corresponding embodiment, it can be seen that in the second call chain (cc2), the function method5(boolpart1, bool part2, ...) is the calling function, the call chain depth depth is 2, and its calling function signature is caller =method5(2...), caller∈Caller. And cc2 is in the file Ac, that is, the file file where the call point is located is Ac. Since there is no control flow relationship in cc2, controls is empty. The calling function method5(bool part1, boolpart2, ...) is in line 24 of the code example, so the calling function declaration position caller_line is 24, the called function is method1(f, VAR1), and the called function signature is method1(1...). The called function is in line 26 of the code example, so the call point position call_line is 26.

[0122] Since cc2 includes the first call chain cc1, that is, the functional macro method1(f, ...) defined in line 19 calls the key API method0("<%s>:" f, VAR1, VAR2) in line 19, it can also be understood as cc2 calling cc1, so the call succ is cc1.

[0123] Since cc5 includes the second call chain cc2, that is, function method8(struct Type2 *argue, boolarg2, bool arg3) indirectly calls cc2 by calling function method5(true, true); cc6 also includes the second call chain cc2, that is, function method8(struct Type2 *argue, bool arg2, bool arg3) indirectly calls cc2 by calling function method5(true, true). Relative to cc2, cc2 is called by cc5 and cc6, so the called preds include cc5 and cc6.

[0124] Figure 5 A schematic diagram of a code static checking framework implemented based on CFCF is shown.

[0125] The framework takes arbitrary source code file directories, historical cross-file call forest CFCF libraries, configuration files, and check item registries as inputs, and goes through (1) a preprocessing phase, (2) a CFCF building phase, and (3) a code inspection phase, and finally outputs an inspection report.

[0126] Among them, the historical CFCF library is used to record the function call relationship obtained by the previous analysis. The function call relationship obtained by the previous analysis can be obtained through the historical CFCF library. In this way, for the function call relationship already in the file, the electronic device does not need to analyze it again, reducing computing power, so that the first data result can be obtained faster, and the code inspection efficiency can be improved.

[0127] The check item registry is used to record the default check item configuration currently provided by the framework. The check item registry may include but is not limited to one or more of the following check items: performance defect check items, syntax check items, variable and scope check items, control flow check items, function and method check items, memory management check items, and code naming standard check items.

[0128] The performance defect check item can be used to check whether there are operations that affect performance in the code. Operations that affect performance may include operations that affect memory space, execution time, and / or energy consumption. For example, time-consuming operations are performed in a for loop, time-consuming operations are performed in a while loop, time-consuming operations are performed in a do loop, time-consuming operations are performed in the user interface UI thread, resource leaks, etc.

[0129] The syntax check item can be used to check whether the keywords, identifiers, and / or operators in the code are used correctly, that is, whether they comply with the usage rules of the programming language.

[0130] Among them, keywords have specific meanings and uses in programming languages ​​and are reserved words in programming languages. Keywords can include data type keywords, control statement keywords, class and object keywords, etc. For example, data type keywords can include Boolean keywords "bool", integer keywords "int", floating point keywords "float", etc.; control statement keywords can include conditional statement keywords "if", loop statement keywords "for", return keywords "return", etc.; class and object keywords can include conditional class keywords "class", private object keywords "private", public object keywords "public", etc.

[0131] Identifiers are names that can be used to name programming elements such as variables, functions, classes, objects, etc. Identifiers can consist of uppercase letters, lowercase literals, numbers, and underscores.

[0132] Operators are symbols or keywords that can be used to perform various operations. Operators may include arithmetic operators, relational operators, logical operators, etc. For example, arithmetic operators may include addition "+", subtraction "-", multiplication "*", division " / ", remainder "%", etc.; relational operators may include equality "==", not equality "!=", greater than ">", less than "<", etc.; logical operators may include logical AND "&&", logical OR "||", logical NOT "!", etc.

[0133] The variable and scope check items can be used to check whether the variables used in the code have been declared, and can also be used to check whether the scope of the variable is correct so that there is no scope conflict.

[0134] Control flow check items can be used to check the legitimacy of loops and recursions, whether there are infinite loops or infinite recursions, and whether there is code that will not be executed. In some scenarios, code that will not be executed can also be called dead code.

[0135] Function and method checks can be used to check whether the number and type of parameters used when calling a function are correct, and can also be used to check whether the type of the function's return value is correct.

[0136] Memory management check items can be used to check whether there is unreleased memory, and can also be used to check the legality of pointers, such as whether there is a null pointer reference or illegal memory access.

[0137] Compiler-specific checks can be used to enable warnings about potential problems based on the compiler settings, and can also be used to provide suggestions for code optimization.

[0138] The code style and specification check items can be used to check whether the naming of variables, functions, classes, etc. complies with the specifications, and can also be used to check whether the format of the code complies with the agreed style.

[0139] The configuration file can be configured by the user, mainly including: turning off certain check items in the check item registry, starting check items in the check item registry, key API sets for building CFCF, etc. It is understandable that if certain check items are turned off, these check items will not be checked and analyzed.

[0140] (1) Preprocessing stage

[0141] The preprocessing stage may include the following analysis processes: (1.1) Performing lexical analysis and syntactic analysis on the source code file to be analyzed to generate an abstract syntax tree set (ASTs); (1.2) Reading the historical CFCF library and parsing it to generate CFCF entities in memory; (1.3) Performing configuration management, which includes one or more of the following: parsing configuration files, checking item registries, extracting check items to be started, whether to overwrite the CFCF library, key API sets, process configuration, etc.

[0142] Among them, lexical analysis can mean decomposing the source code into a series of lexical units, such as keywords, identifiers, operators, etc.

[0143] Syntax analysis can mean organizing lexical units into grammatical structures according to the grammatical rules of the programming language to generate a set of abstract syntax trees (ASTs).

[0144] Abstract syntax tree set ASTs is a data structure in programming language processing, which is used to represent the grammatical structure of source code. In a possible implementation, the compiler or interpreter can parse the source code into a tree-structured ASTs. Each node in ASTs can represent a construct in the source code, such as a variable, operator, control structure, etc.

[0145] It is understandable that after generating ASTs, semantic analysis can also be performed on ASTs to ensure the semantic correctness of the code. Among them, semantic analysis can include: type checking, scope checking, data flow analysis, control flow analysis, etc.

[0146] Type checking is used to check whether the types of variables and / or expressions are correct, for example, checking that an integer cannot be assigned to a string variable. Scope checking is used to check that variables are correctly referenced within their scope, for example, checking whether variables are declared before use. Data flow analysis is used to analyze the definition and use of variables, for example, checking for the use of uninitialized variables, dead code, and other issues. Control flow analysis is used to analyze the control flow structure of the program, for example, checking for illegal jumps or loops.

[0147] (2) CFCF construction phase.

[0148] CFCF is constructed with key API sets and historical CFCF libraries as analysis entry points, and call chains as context. It reverses the files to be analyzed, iteratively searches for call points that call key APIs, and builds direct or indirect call chains, eventually reaching a fixed point and outputting a cross-file call forest CFCF. Figure 5 The target drive can be understood as the process of driving the analyzer to perform reverse analysis with the key API as the target.

[0149] Among them, reaching a fixed point can be understood as the number of call chain sets no longer continues to grow. It can be understood that when the call chain depth reaches the maximum length of the call chain, it means that the fixed point has been reached; or when iteratively searching for call points that call key APIs, if no new call chains are added to the call chain set, it means that the fixed point has been reached.

[0150] As shown in Table 1 below, function 1 is a function for generating CFCF (GenerateCFCF()). This function uses key API set I and cross-function call forest cfcf in the historical CFCF library. old , the abstract syntax tree set ASTs of the file to be analyzed and the maximum length of the call chain l max The input of the function is the final output of the updated cross-function call forest cfcf new .

[0151] For the cross-function call forest cfcf in the historical CFCF library old It is understandable that if code analysis has been performed based on CFCF before executing function 1 this time, the historical cross-function call forest cfcf can be obtained. old . Then we can use cfcf old Get the updated cross-function call forest cfcf new In some cases, such as when the code is modified, if it is not necessary to base on cfcf old Get cfcf new , you can set it in the configuration file, so that the code static inspection framework can generate cfcf based on the key API set new , without considering cfcf old .

[0152] In a possible implementation, the configuration file may include a field identifier for resetting the call chain, which is used to indicate that when generating cfcf new When considering cfcf old For example, the field identifier of the reset call chain can be expressed as resetCallChains. If resetCallChains is set to true, it can indicate that the call chain needs to be reset. In this way, the code static inspection framework will generate cfcf based on the key API set. new , without considering cfcf old If resetCallChains is set to false, it means that the call chain does not need to be reset. In this way, the code static inspection framework will be based on the key API set and cfcf old Generate cfcf new .

[0153] Alternatively, the configuration file may include a field identifier resetCallChains for resetting the call chain, or a field identifier unResetCallChains for not resetting the call chain. If the configuration file includes resetCallChains, it may indicate that the call chain needs to be reset. In this way, the code static inspection framework will generate cfcf based on the key API set. new , without considering cfcf old If the configuration file includes unResetCallChains, it means that the call chain does not need to be reset. In this way, the code static inspection framework will be based on the key API set and cfcf old Generate cfcf new .

[0154] Alternatively, the configuration file may include a field identifier resetCallChains for resetting the call chain. If the configuration file includes resetCallChains, it may indicate that the call chain needs to be reset. In this way, the code static inspection framework will generate cfcf based on the key API set. new , without considering cfcf old If the configuration file does not include resetCallChains, it means that the call chain does not need to be reset. In this way, the code static inspection framework will be based on the key API set and cfcf old Generate cfcf new .

[0155] The specific representation method and specific value of the field identifier of the specific reset call chain can be pre-set by the electronic device, and are not limited in the embodiment of the present application.

[0156] For the maximum length of the call chain l max It is understandable that if the length of the call chain is too long, it may affect the accuracy of code analysis and make the code analysis time longer, affecting the efficiency of code analysis. Therefore, the embodiment of the present application also sets the maximum length of the call chain l max This can prevent the call chain from being too long, thereby improving the accuracy of code analysis, reasonably controlling the duration of code analysis, and improving the efficiency of code analysis.

[0157] It should be noted that the relevant codes in Table 1 are exemplary codes, which can also be called pseudo codes, and are only used to show the main code steps involved in implementing the GenerateCFCF() function. The codes in the actual implementation may be different from the codes in Table 1. The main steps of the GenerateCFCF() function are introduced below.

[0158] In function 1, working set indicates the set of call chains to be visited, which can also be understood as the set to be analyzed. visited indicates the set of function signatures that have been visited. pendingCallChains indicates the set of newly added call chains.

[0159] When looping through the set to be analyzed, the signature of the function that has been traversed can be stored in the function signature set visited. In the next traversal, the function whose signature is in visited will not be traversed again. In this way, the traversal process will not be repeated for the traversed function. The traversed function can also be understood as the visited function.

[0160] The first line of code in function 1 indicates that the visited function signature set visited is initialized to empty.

[0161] The second line of code in function 1 represents the cross-function call forest cfcf in the key API set I and the historical CFCF library old Put it into the newly added call chain set pendingCallChains as the call chain set to be processed in the next step.

[0162] The third line of code in function 1 indicates initialization of cfcf new , and pass the newly added call chain set pendingCallChains to cfcf new .

[0163] The fourth line of code in function 1 indicates that the length of the newly added call chain set pendingCallChains is less than the maximum call chain length l through the FilterByDepth() function. max , and the call chains whose function caller signatures have not been visited are put into the collection to be analyzed, workset.

[0164] Function 1's lines 5 to 14 represent iterative searches for call points that call key APIs, and build direct or indirect call chains to eventually reach a fixed point.

[0165] The fifth line of code indicates that if the length of the set to be analyzed, workset, is greater than 0, it means that the content in workset is not empty, then the workset can be looped through, and the cross-function call forest cfcf can be updated. new If the length of the set to be analyzed, Workset, is equal to 0, indicating that the content in Workset is empty, then the loop traversal of Workset is stopped, thereby outputting the cross-function call forest cfcf new .

[0166] The seventh line of code in function 1 indicates that the function signature set of the newly added call chain in the previous round is marked as visited. It can also be understood as updating the function signature set visited, which includes the previously visited function signature set visited and the signature corresponding to the function to be visited in this loop traversal.

[0167] The 8th and 9th lines of code in function 1 indicate that the callers of the call chain in the workset to be analyzed are visited through the Visit() function, and the new call chain set pendingCallChains is added to cfcf new middle.

[0168] Function 1, lines 10 to 11, indicate that the newly generated call chain is filtered by FilterByDepth() and added to the set to be analyzed, working set, for the next iteration. FilterByDepth() filtering and adding to the set to be analyzed, working set, can be understood as adding the newly generated call chain set pendingCallChains whose length is less than the maximum call chain length l max , and the call chains whose function caller signatures have not been visited are put into the collection to be analyzed, workset.

[0169] It is understandable that the length of the call chain may increase in each loop traversal. In order to prevent the length of the newly added call chain set pendingCallChains from exceeding the set maximum call chain length l max , affecting the accuracy and duration of code analysis, it will determine that the length of the newly added call chain set pendingCallChains is less than the maximum length of the call chain l max , add the length of the newly added call chain set pendingCallChains to be greater than or equal to the maximum length of the call chain l max The call chain is filtered out and the next round of traversal is not executed.

[0170] Table 1

[0171]

[0172] As shown in Table 2 below, Function 2 is a function for visiting and generating a call chain (Visit()). This function takes the abstract syntax tree set ASTs of the file to be analyzed, the call chain set CC to be visited, and the old As input, access the loop variable ast of the ASTs of the analyzed file one by one, and finally output a new call chain set CC new Among them, the call chain set CC to be accessed oldIt can be understood as the set to be analyzed in the embodiment corresponding to Table 1. The new call chain set CC new It can be understood as the newly added call chain set pendingCallChains in the embodiment corresponding to Table 1. The loop variable ast can also be understood as the abstract syntax tree object when looping through ASTs.

[0173] It is understandable that the relevant codes in Table 2 are exemplary codes, which can also be called pseudo codes, and are only used to show the main code steps involved in implementing the Visit() function. The codes in the actual implementation may be different from the codes in Table 2. The main steps of the Visit() function are introduced below.

[0174] The first line of code in function 2 indicates that the new call chain set CC new Initialized to empty.

[0175] Function 2's lines 2 to 19 represent iterative traversal of the abstract syntax tree set ASTs.

[0176] The fourth line of code of function 2 indicates that the function call statement in the loop variable ast is obtained through the GetFuntionCall(ast) function, and the function call statement includes a macro function expansion statement. The macro function expansion statement can also be understood as an expansion statement of a functional macro.

[0177] Function 2's lines 5 to 18 represent iterative traversal of function call statements.

[0178] The 7th line of code of function 2 indicates that the function signature of the function call statement call is obtained by getting the GetSignature(call) function, and the function signature of the function call statement call is obtained by getting the GetCallers(CC old ) function obtains the call chain set CC to be accessed old If the function signature of the function call statement call is not in the call chain set CC to be accessed old If the function is not in the Caller collection, the loop ends and continues to loop the next function call statement call.

[0179] The 8th line of code in function 2 indicates that if the function signature of the function call statement call is in the call chain set CC to be accessed old In the Caller collection, a new call point node is found.

[0180] Function 2's lines 9 to 17 indicate that, starting from the call point node, the parent node of the call point node is searched backwards layer by layer in the abstract syntax tree until the function definition node is found, and a new function call chain is generated based on the call point and the function definition point.

[0181] The 12th line of code of function 2 indicates that if the call point node is a function, or the call point node is a function macro definition, it means that the call point node is a function call point and can be used to call other functions, that is, it can be used to generate a new function call chain CC. new .

[0182] The 14th line of code in function 2 indicates that based on the call point node and the call chain set CC to be visited old , through GenerateCallChains(call, CC old ) function generates a new call chain and updates the call chain set CC new .

[0183] Table 2

[0184]

[0185] (3) Code review phase.

[0186] By traversing CFCF, the code inspection phase can perform cross-file analysis to find the call locations that directly or indirectly call key APIs, thereby further completing the matching of code defect patterns and outputting inspection reports.

[0187] Among them, the inspection report may include the results related to code defects found in one or more files, and the code defects may include but are not limited to one or more of the following: performance defects, syntax defects, variable and scope defects, control flow defects, function and method defects, memory management defects, and code naming convention defects.

[0188] In a possible implementation, the code corresponding to the method of the embodiment of the present application can be integrated into an application, or encapsulated as a software package in (java archive, jar) format. In some implementations, the software package in jar format can be referred to as a jar package. For the case of integration in an application, the application interface can provide a button to trigger the execution of the method of the embodiment of the present application or provide an area for inputting an execution command. For the case of encapsulation as a jar package, the jar package can be integrated into an application or a web page. Similarly, a button to trigger the execution of the method of the embodiment of the present application or an area for inputting an execution command can be provided in the application interface or web page, thereby realizing cross-file analysis of the code, extracting more comprehensive code semantic information, and reducing the situation of code defect omission. Of course, other methods can also be used to execute the method of the embodiment of the present application, without limitation. Among them, the execution command mentioned above may include a command in the format of "java -jar [jar package path] -c [configuration file path] -i [file directory to be analyzed]", and the specific execution command is determined according to the actual situation and code, and the embodiment of the present application is not limited.

[0189] Figure 6 The file checking method of the embodiment of the present application is shown, which is applied to an electronic device. The method includes:

[0190] S601. Obtain a first data structure based on M files, where the first data structure is used to reflect the calling relationship between N functions included in the M files, where M and N are both integers greater than 0.

[0191] In the embodiments of the present application, M and N are used to describe one or more meanings and are not limited to preset fixed values. M files can be understood as one or more files for storing source code. When M is 1, the first data structure can reflect the function call within the file; when M is 1, the first data structure can reflect the cross-file function call.

[0192] The first data structure can be understood as the cross-file call forest CFCF in the above embodiment. The N functions can be understood as one or more key API functions in the above embodiment. The call relationship can be understood as the call chain cc in the above embodiment.

[0193] S602: Check the first data structure to obtain the check results of M files.

[0194] In the embodiment of the present application, the inspection result can be understood as Figure 5 The inspection report in the code inspection phase of (3) of the corresponding embodiment. Specifically, the inspection results of M files obtained according to the first data structure can be referred to Figure 5 The relevant descriptions in the corresponding embodiments are not repeated here.

[0195] The file checking method of the embodiment of the present application provides a code static checking framework based on a first data structure. The first data structure can represent the calling relationship between functions in the source code, and a code static checking algorithm can be constructed based on the first data structure, thereby supporting cross-file source code file analysis, that is, the function calling relationship between multiple source code files can be analyzed. In addition, more comprehensive code semantic information can be extracted, the situation of code defect omission can be reduced, and the stability and performance of electronic equipment operation can be improved.

[0196] Optional, in Figure 6 Based on the corresponding embodiment, the first data structure is a tree structure, and the first data structure includes a first set and a second set. The first set is a leaf set of the tree structure, and the second set is a vertex set of the tree structure. The first set includes N functions and calling relationships related to the N functions, and the second set includes N functions.

[0197] In the embodiment of the present application, the first set can be understood as CC in the above embodiment, that is, the set of function call chains cc.

[0198] The second set can be understood as I in the above embodiment, that is, the key API set.

[0199] The tree structure can better represent the calling hierarchy relationship between data, accurately represent complex function relationships, and can quickly search and traverse any leaf in the tree, so that code defect inspection can be performed efficiently and flexibly based on the first data structure.

[0200] Optional, in Figure 6 Based on the corresponding embodiment, the first data structure CFCF satisfies the following relationship:

[0201] CFCF = (CC, I).

[0202] Among them, CC represents the first set and I represents the second set.

[0203] In the embodiment of the present application, the first data structure CFCF can refer to the relevant description of the cross-file call forest CFCF in the embodiment, and will not be repeated here.

[0204] Through the first set and the second set, a relatively complete cross-file call forest CFCF with a tree structure can be constructed, so that in cross-file code analysis, code semantic information can be more comprehensively represented.

[0205] Optional, in Figure 6 On the basis of the corresponding embodiment, the N functions include the target function, the first set includes the target function and L call relations related to the target function, L is an integer greater than 0, and any call relation cc of the L call relations satisfies the following relationship:

[0206] cc = (depth, succ, preds, callsite).

[0207] Among them, depth represents the function call depth of any calling relationship, succ represents the third set, preds represents the fourth set, and callsite represents the relevant information of any calling relationship; the third set includes other calling relationships among the L calling relationships called by any calling relationship, and the fourth set includes other calling relationships among the L calling relationships that call any calling relationship.

[0208] In the embodiment of the present application, the target function can be understood as a key API function among one or more key API functions.

[0209] L is used to describe one or more meanings and is not limited to a preset fixed value. Figure 3 In the corresponding embodiment, taking the target function as method0(…) as an example, the L calling relationships may include: cc1, cc2, cc3, cc4, cc5, cc6.

[0210] exist Figure 4 In the corresponding embodiment, any call relationship cc can be understood as cc2. Then the third set includes cc1; the fourth set includes cc5 and cc6. For details about the relationship satisfied by cc2, please refer to Figure 4 The relevant description of the corresponding embodiments will not be repeated here.

[0211] According to the relationship satisfied by any calling relationship cc, the file to be analyzed can be analyzed, the calling points of the key API functions can be iteratively found, and a direct or indirect calling chain can be constructed.

[0212] Optional, in Figure 6 Based on the corresponding embodiment, the function call depth is less than or equal to a preset value.

[0213] In the embodiment of the present application, the preset value can be understood as Figure 5 (2) Maximum length of call chain l in the CFCF construction phase of the corresponding embodiment max .

[0214] It is understandable that if the function call depth is greater than the preset value, that is, the length of the call chain is too long, it may affect the accuracy of code analysis and make the code analysis time longer, affecting the efficiency of code analysis. Therefore, the embodiment of the present application also sets the maximum length of the call chain l max , which is used to limit the depth of function calls, so that the call chain will not be too long, thereby improving the accuracy of code analysis, reasonably controlling the duration of code analysis, and improving the efficiency of code analysis.

[0215] Optional, in Figure 6 Based on the corresponding embodiments, the callsite related information of any call relationship satisfies the following relationship:

[0216] callsite = (Caller, File, Controls, Caller_line, Callee, Call_line).

[0217] Among them, Caller represents the calling function signature, File represents the file where the calling function is located, Controls represents the control flow relationship, Caller_line represents the position of the calling function in the file, Callee represents the called function signature, and Call_line represents the position of the called function in the file; the calling function signature includes a combination of the calling function name and the number of parameters; the called function signature includes a combination of the called function name and the number of parameters; the control flow relationship includes one or more of the following control flow relationships: control flow relationships related to for loops, control flow relationships related to if conditional statements, control flow relationships related to while loops, control flow relationships related to do loops, and control flow relationships related to switch selection statements.

[0218] In the embodiments of the present application, reference can be made to the relevant descriptions in the above embodiments for callsite, which will not be repeated here. Callsite can record the relevant information related to any call relationship cc in more detail, including the calling function, the called function, the number of lines of code corresponding to the calling function, the number of lines of code corresponding to the called function, etc., which is conducive to the analysis of code defects.

[0219] Optional, in Figure 6 Based on the corresponding embodiments, the inspection results include results related to code defects detected in M ​​files, and the code defects include one or more of the following: performance defects, syntax defects, variable and scope defects, control flow defects, function and method defects, memory management defects, and code naming convention defects.

[0220] In the embodiment of the present application, the inspection result can be understood as the above Figure 5 The inspection report output in the code inspection phase (3) of the corresponding embodiment is not described in detail here. The inspection results may include results related to code defects, so that developers can modify the code based on the inspection results to obtain higher quality code and make the software run more stably.

[0221] Optional, in Figure 6On the basis of the corresponding embodiments, obtaining a first data structure based on M files may include: performing lexical analysis and syntactic analysis on the code in the M files to obtain an abstract syntax tree set ASTs; looping through the first function node in the ASTs to find out whether the first function node has a parent node, wherein the function signature of the first function node is in the calling function signature of the first set; if the first function node has a parent node, adding the function corresponding to the parent node to the first set of the first data structure, and updating the first function node to the parent node, and continuing to traverse the first function node in the ASTs; if the first function node does not have a parent node, ending the traversal of the ASTs; and outputting the first data structure.

[0222] In the embodiment of the present application, the first function node can be understood as Figure 5 The corresponding embodiment (2) is the call point node in function 2 in the CFCF construction phase. The call function signature can be understood as the call function signature Caller in any call relationship related information callsite. The specific process of obtaining the first data structure based on M files can refer to Figure 5 The relevant description in the (2) CFCF construction phase of the corresponding embodiment will not be repeated here.

[0223] The embodiment of the present application constructs an algorithm based on the first data structure to realize automatic analysis of source code files. By iteratively searching for call points of key API functions, a direct or indirect call chain is constructed, so that cross-file defect inspection of the code can be performed, and finally a defect inspection report is output.

[0224] Optional, in Figure 6 On the basis of the corresponding embodiment, a second data structure is also stored in the electronic device, and the second data structure is the first data structure obtained last time. The function signature of the first function node is in the calling function signature of the first set, and the first set includes the calling relationship related to the first function in the second data structure.

[0225] In the embodiment of the present application, the second data structure can be understood as Figure 5 The historical CFCF library in the corresponding embodiment. Through the historical CFCF library, the function call relationship obtained by the previous analysis can be obtained. In this way, for the function call relationship already in the file, the electronic device does not need to analyze it again, reducing computing power, so that the first data result can be obtained faster, and the code inspection efficiency is improved.

[0226] Optional, in Figure 6On the basis of the corresponding embodiment, before checking the first data structure, it can also include: obtaining configuration information in the configuration file and / or the check item registry; checking the first data structure to obtain the inspection results of M files, which can include: based on the configuration information, checking the first data structure to obtain the inspection results of M files.

[0227] In the embodiment of the present application, the check item registry and configuration file can refer to Figure 5 The relevant descriptions in the corresponding embodiments are not repeated here. Users or developers can configure and modify the check items in the configuration file, so that users or developers can conveniently and flexibly check code defects by modifying the configuration file, reduce code modifications, and facilitate function implementation and maintenance.

[0228] Optional, in Figure 6 Based on the corresponding embodiments, the check item registry includes one or more of the following check items: performance defect check items, syntax check items, type check items, variable and scope check items, control flow check items, function and method check items, memory management check items, and code naming convention check items; the configuration file includes check items that are closed in the check items, check items that are enabled in the check items, and / or N functions used to construct the first data structure.

[0229] In the embodiment of the present application, the check item registration table can refer to Figure 5 The description of the check item registration table in the corresponding embodiment will not be repeated. It can be understood that if the configuration file does not include N functions for constructing the first data structure, all functions in the M files can be analyzed.

[0230] According to the check items, the code in M ​​files can be checked for defects, so that developers can find and modify the defects in the code in advance and make modifications. This improves the robustness of the code, so that the electronic devices running the code can run stably and reduce the black screen, flash back and other situations of the electronic devices.

[0231] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0232] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the method steps of each example described in the embodiment disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0233] The embodiment of the present application can divide the functional modules of the device implementing the method according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0234] like Figure 7 FIG. 7 is a schematic diagram of a chip structure provided by an embodiment of the present application. The chip 700 includes one or more (including two) processors 701 , a communication line 702 , a communication interface 703 and a memory 704 .

[0235] In some implementations, the memory 704 stores the following elements: executable modules or data structures, or a subset thereof, or an extended set thereof.

[0236] The method described in the above embodiment of the present application can be applied to the processor 701, or implemented by the processor 701. The processor 701 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 701 or an instruction in the form of software. The above processor 701 can be a general-purpose processor (for example, a microprocessor or a conventional processor), a digital signal processor (digital signal processing, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC), a field-programmable gate array (field-programmable gate array, FPGA) or other programmable logic devices, discrete gates, transistor logic devices or discrete hardware components. The processor 701 can implement or execute the methods, steps and logic block diagrams related to each processing disclosed in the embodiment of the present application.

[0237] The steps of the method disclosed in the embodiment of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. Among them, the software module can be located in a mature storage medium in the field such as a random access memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable read only memory (EEPROM). The storage medium is located in the memory 704, and the processor 701 reads the information in the memory 704 and completes the steps of the above method in combination with its hardware.

[0238] The processor 701 , the memory 704 , and the communication interface 703 may communicate with each other via the communication line 702 .

[0239] In the above embodiments, the instructions stored in the memory for execution by the processor may be implemented in the form of a computer program product, wherein the computer program product may be pre-written in the memory, or may be downloaded and installed in the memory in the form of software.

[0240] The embodiment of the present application also provides a computer program product including one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. For example, the available medium may include a magnetic medium (e.g., a floppy disk, a hard disk or a tape), an optical medium (e.g., a digital versatile disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0241] The present application also provides a computer-readable storage medium. The methods described in the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. Computer-readable media may include computer storage media and communication media, and may also include any medium that can transfer a computer program from one place to another. The storage medium may be any target medium that can be accessed by a computer.

[0242] As a possible design, the computer readable medium may include a compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM or other optical disc storage; the computer readable medium may include a magnetic disk storage or other magnetic disk storage device. Moreover, any connection line may also be appropriately referred to as a computer readable medium. For example, if the software is transmitted from a website, server or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically using lasers.

[0243] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processing unit of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

Claims

1. A file inspection method, applied to an electronic device, characterized in that: The method comprises: Acquire a first data structure based on M files, the first data structure is used to reflect the calling relationships between N functions included in the M files, M and N are both integers greater than 0, the first data structure is a cross-file call forest CFCF, the first data structure is a tree structure, the first data structure includes a first set and a second set, the first set is a leaf set of the tree structure, the second set is a vertex set of the tree structure, the first set includes the N functions and the calling relationships between the N functions, and the second set includes the N functions; Checking the first data structure to obtain the checking results of the M files; The obtaining of the first data structure based on the M files includes: Perform lexical analysis and grammatical analysis on the codes in the M files to obtain an abstract syntax tree set ASTs; Loop through the first function node in the ASTs to find out whether the first function node has a parent node, wherein the function signature of the first function node is in the calling function signature of the first set; If the first function node has a parent node, add the function corresponding to the parent node to the first set of the first data structure, update the first function node to the parent node, and continue to traverse the first function node in the ASTs; If the first function node does not have a parent node, then end the traversal of the ASTs; outputting the first data structure; The first data structure CFCF satisfies the following relationship: CFCF = (CC, I); Wherein, the CC represents the first set, and the I represents the second set; The N functions include a target function, the first set includes the target function and L call relationships related to the target function, L is an integer greater than 0, and any call relationship cc of the L call relationships satisfies the following relationship: cc = (depth, succ, preds, callsite); Among them, the depth represents the function call depth of any one of the calling relationships, the succ represents the third set, the preds represents the fourth set, and the callsite represents the relevant information of any one of the calling relationships; the third set includes other calling relationships among the L calling relationships called by any one of the calling relationships, and the fourth set includes other calling relationships among the L calling relationships that call any one of the calling relationships.

2. The method according to claim 1, characterized in that The function call depth is less than or equal to a preset value.

3. The method according to claim 1, characterized in that The callsite information of any calling relationship satisfies the following relationship: callsite = (Caller, File, Controls, Caller_line, Callee, Call_line); Wherein, the Caller represents the signature of the calling function, the File represents the file where the calling function is located, the Controls represents the control flow relationship, the Caller_line represents the position of the calling function in the file, the Callee represents the signature of the called function, and the Call_line represents the position of the called function in the file; the calling function signature includes a combination of the calling function name and the number of parameters; the called function signature includes a combination of the called function name and the number of parameters; The control flow relationship includes one or more of the following control flow relationships: a control flow relationship related to a for loop, a control flow relationship related to an if conditional statement, a control flow relationship related to a while loop, a control flow relationship related to a do loop, and a control flow relationship related to a switch selection statement.

4. The method according to claim 1, characterized in that: The inspection results include results related to code defects detected in the M files, and the code defects include one or more of the following: performance defects, syntax defects, variable and scope defects, control flow defects, function and method defects, memory management defects, and code naming convention defects.

5. The method according to claim 1, characterized in that: The electronic device also stores a second data structure, which is the first data structure obtained last time. The function signature of the first function node is in the calling function signature of the first set, and the first set includes the calling relationship related to the first function in the second data structure.

6. The method according to claim 1, characterized in that Before checking the first data structure, the method further includes: Get configuration information from configuration files and / or check item registries; The checking of the first data structure to obtain the checking results of the M files includes: Based on the configuration information, the first data structure is checked to obtain the checking results of the M files.

7. The method according to claim 6, characterized in that The check item registry includes one or more of the following check items: performance defect check items, syntax check items, variable and scope check items, control flow check items, function and method check items, memory management check items, and code naming specification check items; The configuration file includes closed check items among the check items, enabled check items among the check items, and / or the N functions used to construct the first data structure.

8. An electronic device, characterized in that: The electronic device comprises: one or more processors and a memory; The memory is coupled to the one or more processors, and the memory is used to store computer program codes, wherein the computer program codes include computer instructions, and the one or more processors call the computer instructions to enable the electronic device to perform the method as claimed in any one of claims 1 to 7.

9. A chip system, characterized in that: The chip system is applied to an electronic device, and the chip system includes one or more processors, and the one or more processors are used to call computer instructions so that the electronic device executes the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises computer instructions, and when the computer instructions are executed on an electronic device, the electronic device executes the method as claimed in any one of claims 1 to 7.

11. A computer program product, characterized in that The computer program product comprises a computer program code, and when the computer program code is run on an electronic device, the electronic device is caused to perform the method according to any one of claims 1 to 7.

Images