A method and system for constructing a parameter of a constructor unsigned type pointer

Abstract

The application discloses a method and system for constructing a parameter of an unsigned type pointer, and belongs to the technical field of software testing, and comprises the following steps: collecting function call information and pointer allocation information through pre-compiled stage code insertion; analyzing and determining memory structure information corresponding to an unsigned type pointer parameter based on the collected information; and constructing the unsigned type pointer parameter in unit testing according to the memory structure information. The application solves the problem that the length and structure of a memory pointed to by a void unsigned pointer cannot be accurately determined in automatic unit testing, avoids test false positives caused by unmatched pointer structures, and improves the accuracy and reliability of unit testing.

Description

Technical Field

[0001] This application relates to the field of software testing, specifically to a method and system for constructing parameters of an unsigned pointer type constructor. Background Technology

[0002] As software code complexity increases, large-scale software can have millions or even tens of millions of lines of code. To ensure code quality, rigorous testing is necessary, but relying solely on manual testing for such a large volume of code would consume enormous human and material resources.

[0003] To address these issues, automated testing technologies have emerged and gained widespread application. Among them, symbolic execution engines (such as KLEE), as advanced automated test case generation tools, can automatically generate test cases covering all logical branches of a function through formal methods and symbolic execution techniques. These tools, through standardized interface calls, can systematically explore program execution paths, offering significant advantages such as high automation, comprehensive test coverage, and objective and accurate results, and have been widely used in various software testing scenarios.

[0004] However, existing automated testing tools still have significant technical limitations in practical applications. A key prerequisite for using these tools is the explicit specification of the input parameter type information of the function under test. For common data types (such as basic types like int and float, or defined structure types), this condition is relatively easy to meet; however, when the input parameter of the function under test is void... When dealing with unsigned pointers, the actual length of the memory region pointed to by the pointer or the specific structure type cannot be determined, making it difficult for automated testing tools to accurately construct appropriate test parameters.

[0005] Specifically, when facing void When using pointer-type parameters, testers typically construct pointers of arbitrary length as test parameters. This practice often differs significantly from the actual memory layout and data structures of a program during runtime, leading to a mismatch between test results and actual program logic, resulting in a large number of false positives. These false positives not only reduce the accuracy and reliability of automated testing but also increase the workload of test result analysis, requiring testers to expend extra effort to distinguish between real defects and false positives generated by the testing tools.

[0006] Therefore, accurately handling the testing of unsigned pointer parameters has become a key bottleneck in improving the practicality and reliability of automated testing tools. Summary of the Invention

[0007] This application provides a method and system for constructing parameters of an unsigned pointer, which can solve the technical problem in the prior art that the inability to determine the actual memory structure of the input parameters of the unsigned pointer leads to a large number of false alarms in automated testing tools.

[0008] In a first aspect, embodiments of this application provide a method for constructing parameters of an unsigned pointer type constructor, comprising the following steps: Function call information and pointer allocation information are collected through code instrumentation during the pre-compilation stage; Based on the collected information, the memory structure information corresponding to the input parameters of the unsigned pointer type is determined; Construct the unsigned pointer input parameters in the unit test based on the memory structure information.

[0009] In conjunction with the first aspect, in one implementation, the pre-compilation stage code instrumentation uses the clang AST tool to automatically identify function call points and memory allocation functions, and inserts trace code at the corresponding locations.

[0010] In conjunction with the first aspect, in one implementation, the step of collecting function call information includes: The clang AST tool was used to analyze the source code, identify all function definitions, and record their file names and line numbers in the first file information table. Insert function tracing code at the beginning of the function body of each function definition. The function tracing code is used to obtain the function name, the address of the function input parameter pointer, and the execution time point.

[0011] In conjunction with the first aspect, in one implementation, when inserting function tracing code, debugging information with a special identifier is inserted before the function tracing code, and debugging information containing filenames and line numbers generated based on the first file information table is inserted after the function tracing code.

[0012] In conjunction with the first aspect, in one implementation, the step of collecting pointer allocation information includes: The clang AST tool is used to identify memory allocation function call points and record their function names, file names, and line numbers in a second file information table. After each memory allocation function call, pointer tracing code is inserted. This pointer tracing code is used to obtain the pointer address, pointer type, pointer length, and corresponding variable.

[0013] In conjunction with the first aspect, in one implementation, when inserting pointer tracing code, debugging information with a special identifier is inserted before the pointer tracing code, and debugging information containing filenames and line numbers generated based on a second file information table is inserted after the pointer tracing code.

[0014] In conjunction with the first aspect, in one implementation, during the pre-compilation stage code instrumentation, the memory release interface is masked to ensure that the memory pointer is not released during the program's lifetime, thus maintaining the uniqueness of the pointer address.

[0015] In conjunction with the first aspect, in one implementation, the step of analyzing and determining the memory structure information corresponding to the input parameter of the unsigned pointer based on the collected information includes: searching for the corresponding memory structure information in the pointer allocation information using the address of the unsigned pointer as the key.

[0016] Secondly, embodiments of this application provide a system for parameters of an unsigned pointer to a constructor, comprising the following modules: The pre-compilation processing module is used for pre-compilation code instrumentation of the source code. The information gathering module is used to collect function call information and pointer allocation information through instrumentation code; The analysis module is used to determine the memory structure information corresponding to the input parameters of the unsigned pointer based on the collected information; The test case generation module is used to construct unsigned pointer input parameters in unit tests based on the memory structure information. The debugging information protection module is used to insert specially identified debugging information before and after the tracing code to maintain the integrity of the original debugging information.

[0017] In conjunction with the second aspect, in one implementation, the pre-compilation processing module includes: The function identification unit is used to analyze the source code using clang AST tools, identify all function definitions, and record their file names and line numbers in the first file information table; The function tracing unit is used to insert function tracing code at the beginning of the function body of each function definition. The function tracing code is used to obtain the function name, the function input parameter pointer address and the execution time point. The pointer allocation identification unit is used to identify memory allocation function call points using clang AST tools and record their function name, file name, and line number information to the second file information table; A pointer tracing unit is used to insert pointer tracing code after each memory allocation function call. The pointer tracing code is used to obtain the pointer address, pointer type, pointer length, and corresponding variable. The memory management unit is used to shield the memory release interface to ensure that the memory pointer is not released during the program's lifetime and to maintain the uniqueness of the pointer address.

[0018] The beneficial effects of the technical solutions provided in this application include: By using code instrumentation during the pre-compilation phase, function call information and pointer allocation information can be effectively collected without modifying the source code. Analyzing this information accurately determines the actual memory structure of unsigned pointers. Test input parameters are then constructed based on this actual memory structure information, ensuring that test cases match the actual program logic. This effectively overcomes the limitations of existing automated testing tools that require manual specification of function input parameter types and cannot determine void values. This significantly improves the accuracy and reliability of automated unit testing for large software applications by addressing false positives caused by the length of memory or structures pointed to by unsigned pointers, and reduces the workload of testers. Attached Figure Description

[0019] Figure 1 A flowchart illustrating an embodiment of a method for constructing an unsigned type pointer as a parameter in this application; Figure 2 This is a flowchart illustrating one embodiment of step S1; Figure 3 This is a flowchart illustrating one embodiment of step S2; Figure 4 This is a flowchart illustrating one embodiment of step S3; Figure 5 A schematic diagram of the functional modules of a system that serves as the parameter of an unsigned type pointer in the constructor of this application; Figure 6 This is a functional module diagram of one embodiment of the pre-compilation processing module in the present application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0022] In one aspect, embodiments of this application provide a method for constructing parameters of an unsigned pointer type constructor.

[0023] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of a method for constructing an unsigned type pointer as a parameter in this application. Figure 1As shown, the methods that take an unsigned pointer as a parameter in the constructor include: Step S1: Collect function call information and pointer allocation information through code instrumentation during the pre-compilation stage; Step S2: Analyze and determine the memory structure information corresponding to the input parameters of the unsigned pointer based on the collected information; Step S3: Construct the unsigned pointer input parameters in the unit test based on the memory structure information.

[0024] In this embodiment, code instrumentation during the pre-compilation stage effectively collects function call and pointer allocation information without modifying the source code. By analyzing this information, the true memory structure of unsigned pointers is accurately determined. Test input parameters are constructed based on this true memory structure information, ensuring that test cases match the actual program logic. This effectively overcomes the limitations of existing automated testing tools that require manual specification of function input parameter types and cannot determine void. This significantly improves the accuracy and reliability of automated unit testing for large software applications by addressing false positives caused by the length of memory or structures pointed to by unsigned pointers, and reduces the workload of testers.

[0025] Furthermore, in one embodiment, the pre-compilation stage code instrumentation uses the clang AST tool to automatically identify function call points and memory allocation functions, and inserts tracing code at the corresponding locations.

[0026] In this embodiment, the clang AST tool can accurately analyze the source code abstract syntax tree, automatically identify all function definitions and memory allocation function call points, and ensure that the tracking code is inserted at the correct position at the beginning of the function body and after the memory allocation operation. This allows for the accurate collection of complete function call information and pointer allocation information, thereby accurately determining the real memory structure of the unsigned pointer. This enables testers to construct test cases that conform to the actual program logic based on the real content structure.

[0027] Furthermore, in one embodiment, the step of collecting function call information includes: The clang AST tool was used to analyze the source code, identify all function definitions, and record their file names and line numbers in the first file information table. Insert function tracing code at the beginning of the function body of each function definition. The function tracing code is used to obtain the function name, the address of the function input parameter pointer, and the execution time point.

[0028] In this embodiment, the clang AST tool is used to traverse the abstract syntax tree to identify all function definitions, record their file names and line numbers in the first file information table, and insert function tracing code at the beginning of the function body to obtain the function name, input parameter pointer address and execution time point. This ensures the accurate capture of the unsigned pointer address when the function is called, and provides a reliable data source for subsequent analysis to determine the real memory structure of the pointer.

[0029] Furthermore, in one embodiment, when inserting function tracing code, debugging information with a special identifier is inserted before the function tracing code, and debugging information containing filenames and line numbers generated based on the first file information table is inserted after the function tracing code.

[0030] In this embodiment, specially identified debugging information enables the compiler to recognize function tracing code as an independent code segment, while the original location information stored in the first file information table ensures that subsequent code can still be correctly mapped to the original source code location. This approach ensures the integrity of debugging information while collecting function call information, avoiding debugging information offsets caused by code instrumentation. The system can accurately establish the correspondence between function call points and pointer allocation points, providing a reliable data foundation for subsequently determining the actual memory structure of unsigned pointers, ensuring that the constructed test cases match the actual program logic, and reducing false positives in testing.

[0031] Furthermore, in one embodiment, the step of collecting pointer allocation information includes: The clang AST tool is used to identify memory allocation function call points and record their function names, file names, and line numbers in a second file information table. After each memory allocation function call, pointer tracing code is inserted. This pointer tracing code is used to obtain the pointer address, pointer type, pointer length, and corresponding variable.

[0032] In this embodiment, after identifying the memory allocation function call point (such as malloc, calloc, etc.), its location information is recorded in the second file information table. Immediately after the call, pointer tracing code is inserted to capture the pointer address, type, length, and corresponding variables, ensuring complete structural information is obtained at the source of pointer allocation. This avoids the problem of not being able to determine void in traditional methods. The problem of inaccurate test case construction caused by the length of memory pointed to by the pointer or the structure is solved by making the constructed unsigned pointer test cases completely match the actual program memory layout, which significantly reduces the false alarm rate.

[0033] Furthermore, in one embodiment, when inserting pointer tracing code, debugging information with a special identifier is inserted before the pointer tracing code, and debugging information containing filenames and line numbers generated based on a second file information table is inserted after the pointer tracing code.

[0034] In this embodiment, specially identified debugging information enables the compiler to recognize pointer tracing code as an independent code segment, while the original location information stored in the second file information table ensures that subsequent code can still be correctly mapped to the original source code location. This approach ensures the integrity of debugging information during pointer allocation information collection and avoids source code location mapping errors caused by instrumentation. The system can accurately correlate the memory structure information at the time of pointer allocation with the pointer usage information at the time of function call, thereby determining the true memory structure of the unsigned pointer. This ensures that the subsequently constructed test cases are consistent with the actual program memory layout, effectively reducing false positives caused by pointer structure mismatches.

[0035] In the aforementioned embodiments, the first file information table stores the filenames and line numbers of all functions in the source code, and the second file information table stores the function name, filename, and line number of memory allocation functions in the source code. Therefore, when inserting debugging information generated based on the file information tables after tracing the code, the system uses the #line directive to map the source code location of subsequent code back to the original source file location.

[0036] Considering the positional mapping between the source code and the preprocessed file, in other embodiments, the first file information table can also store the positional information of all functions in the preprocessed file, and the second file information table can also store the positional information of memory allocation functions in the preprocessed file. In this case, the debugging information inserted after the code trace uses the #line directive to map the subsequent code positions back to the corresponding positions in the preprocessed file.

[0037] The main difference between these two implementation methods is: Source code benchmarking: The code location displayed by the debugger directly corresponds to the original source file, which is easy for developers to understand, but requires maintaining the location mapping between the source code and the preprocessed file.

[0038] Preprocessed file benchmark method: The code location displayed by the debugger corresponds to the preprocessed file of the original source file. This method is simpler to implement, but developers need to refer to the preprocessed file to locate problems.

[0039] Regardless of the method used, the core objective is to ensure the integrity of debugging information, enabling the debugger to accurately locate code positions and avoid debugging information misalignment caused by code instrumentation, thereby providing a reliable foundation for the analysis of the actual memory structure with unsigned pointer parameters.

[0040] Furthermore, in one embodiment, during the pre-compilation stage code instrumentation, the memory release interface is masked to ensure that the memory pointer is not released during the program's lifetime, thus maintaining the uniqueness of the pointer address.

[0041] In this embodiment, the memory release function call is redirected to a no-operation implementation, so that all allocated memory remains in a valid state, thereby ensuring a one-to-one correspondence between pointer addresses and memory structures.

[0042] Furthermore, in one embodiment, the step of analyzing and determining the memory structure information corresponding to the input parameter of the unsigned pointer based on the collected information includes: using the address of the unsigned pointer as the key to search for the corresponding memory structure information in the pointer allocation information.

[0043] In this embodiment, the uniqueness of pointer addresses during program execution is utilized to precisely match the unsigned pointer address captured during function calls with the memory structure information recorded during pointer allocation. When unit tests require constructing unsigned pointer input parameters, the system queries the record of that pointer address in the pointer allocation information table to obtain the corresponding pointer type, length, and variable information, thereby determining the actual memory structure of the unsigned pointer. This approach avoids the inability of traditional automated testing tools to determine void. The issue of manually specifying the pointer structure when determining the actual memory type pointed to by a pointer is addressed by enabling the system to automatically identify the true memory type and structure of an unsigned pointer. Furthermore, this avoids the problems associated with traditional methods of handling `void`. By assuming arbitrary pointer lengths, the constructed test cases can accurately reflect the actual memory layout of the program during runtime, effectively reducing false alarms caused by pointer structure mismatches and improving the accuracy and reliability of automated unit testing.

[0044] In one specific embodiment, refer to Figure 2 The pre-compilation stage collects function call and pointer allocation information through code instrumentation, specifically including the following steps: S101. Use the clang AST tool to analyze the software source code, obtain the filenames and line numbers of all functions, and save them to the first file information table. This process is achieved by traversing the abstract syntax tree of the source code, which can accurately identify the location information of each function definition, providing a foundation for subsequent debugging information protection.

[0045] S102. Perform pre-compilation processing on the software source code to generate a pre-processed file.

[0046] S103. Use the clang AST tool to analyze the preprocessed file generated in step S102, traversing each function and masking the memory release interface. This step ensures that memory allocated during program execution is not actually released, maintaining the uniqueness of pointer addresses throughout the entire program's lifetime and providing a reliable foundation for subsequent pointer address mapping.

[0047] S104. Use the clang AST tool to analyze the preprocessed file and insert function tracing code at the beginning of the function body of all functions to obtain key information such as function name, function parameter pointer addresses, and execution time. To protect the original debugging information from being destroyed, insert specially identified debugging information before the function tracing code and insert #line instruction debugging information containing the original file name and line number based on the first file information table after the function tracing code.

[0048] S105. Use the clang AST tool to identify all functions involving pointer memory allocation, recording their function names, file names, and line numbers in a second file information table. Then, insert pointer tracing code after each memory allocation operation to obtain key information such as pointer address, pointer type, pointer length, and corresponding variables. Similarly, insert specially marked debugging information before the pointer tracing code and #line instruction debugging information generated based on the second file information table after the pointer tracing code to ensure a consistent debugging experience.

[0049] S106. Compile the modified preprocessed file to generate an executable program.

[0050] S107. Run the executable file. After the program finishes running, the information obtained from the function tracing code will be stored in the function tracing information table; the information obtained from the pointer tracing code will be stored in the pointer tracing information table. These information tables record the complete context of function calls and pointer allocations, providing a data foundation for subsequent analysis of the actual memory structure of unsigned pointers.

[0051] This embodiment achieves complete capture of function call and pointer allocation information through automated code instrumentation during the pre-compilation stage. Simultaneously, it ensures developers are unaware of code modifications through specially identified debugging information and #line directive protection mechanisms. The system can accurately establish the correspondence between function call points and pointer allocation points, providing reliable technical support for constructing accurate unsigned pointer input parameters in unit testing.

[0052] In one specific embodiment, refer to Figure 3 Based on the collected information, the memory structure information corresponding to the input parameter of the unsigned pointer is determined, specifically including the following steps: S201. Traverse the functions in the function tracking information table and check if there are any more functions that need to be analyzed. If yes, proceed to step S202; otherwise, end the information analysis process.

[0053] S202. Check if the input parameters of the current function include void. Type pointer. If yes, proceed to step S203; otherwise, return to step S201 to continue processing the next function.

[0054] S203, void The pointer address corresponding to the pointer is used as the key to look up the allocation information of the pointer in the pointer tracking information table, and to obtain which function the pointer was allocated in, as well as the corresponding pointer type, pointer length, and variable information corresponding to the pointer length.

[0055] S204. Store the pointer type, pointer length and corresponding variable information obtained in step S203 in the input parameter structure construction information table with "function name_parameter name" as the key.

[0056] This embodiment solves the problem of not being able to determine void in automated unit testing by associating function call information with pointer allocation information. The system addresses the issue of the actual memory type and length pointed to by pointers. It automatically identifies the true memory structure of unsigned pointers, avoiding the tedious process of manually specifying the pointer structure required in traditional methods. This provides reliable data support for constructing accurate unsigned pointer test cases. This precise mapping mechanism based on pointer addresses ensures a high degree of matching between test cases and actual program logic, effectively reducing false positives caused by pointer structure mismatches.

[0057] In one specific embodiment, refer to Figure 4 The process of constructing unsigned pointer input parameters for unit testing based on the memory structure information includes the following steps: S301. Iterate through the functions in the file under test and check if there are any functions that need to be unit tested. If yes, proceed to step S302; otherwise, end the test process.

[0058] S302. Determine whether the current function needs unit testing. If yes, proceed to step S303; otherwise, return to step S301 to continue processing the next function.

[0059] S303. Iterate through and construct the input parameters of the current function, and check whether all input parameters have been constructed. If so, return to step S301 to process the next function; otherwise, execute step S304.

[0060] S304. Determine if the current input parameter type is void. Type pointer. If yes, proceed to step S305; otherwise, construct the structure according to the actual structure type of the input parameter, and then return to step S303 to continue processing the next input parameter.

[0061] S305. Using "function name_parameter name" as the key, search the parameter structure construction information table for the corresponding pointer type, pointer length, and corresponding variable information, and construct a void function based on this information. The type pointer is input as a parameter, and then the process returns to step S303 to continue processing the next parameter.

[0062] This embodiment achieves accurate construction of void type pointer parameters by utilizing the pointer structure information stored in the input parameter structure construction information table. The system can automatically identify the actual memory structure of unsigned pointers, avoiding the arbitrary length assumptions made for void pointers in traditional methods, and ensuring that the constructed test cases perfectly match the actual program memory layout. This construction mechanism based on precise pointer address mapping effectively solves the problem of not being able to determine void in automated unit testing. Addressing the issue of the actual memory type and length pointed to by pointers significantly reduces false alarms in tests caused by pointer structure mismatches, thereby improving the accuracy and reliability of unit tests.

[0063] Secondly, embodiments of this application also provide a system for constructor parameters of unsigned type pointers.

[0064] In one embodiment, reference is made to Figure 5 , Figure 5 This is a functional module diagram of an embodiment of a system that constructs an unsigned type pointer as a parameter in this application. (See diagram below.) Figure 5 As shown, the system of parameters for an unsigned pointer type constructor includes: Pre-compilation processing module 1 is used for pre-compilation code instrumentation of the source code; Information gathering module 2 is used to collect function call information and pointer allocation information through instrumentation code; Analysis module 3 is used to determine the memory structure information corresponding to the input parameters of the unsigned pointer based on the collected information; Test case generation module 4 is used to construct unsigned pointer input parameters in unit tests based on the memory structure information; The debugging information protection module 5 is used to insert specially identified debugging information before and after the tracing code in order to maintain the integrity of the original debugging information.

[0065] In this embodiment, code instrumentation during the pre-compilation stage effectively collects function call and pointer allocation information without modifying the source code. By analyzing this information, the true memory structure of unsigned pointers is accurately determined. Test input parameters are constructed based on this true memory structure information, ensuring that test cases match the actual program logic. This effectively overcomes the limitations of existing automated testing tools that require manual specification of function input parameter types and cannot determine void. This significantly improves the accuracy and reliability of automated unit testing for large software applications by addressing false positives caused by the length of memory or structures pointed to by unsigned pointers, and reduces the workload of testers.

[0066] Furthermore, in one embodiment, reference is made to Figure 6 The pre-compilation processing module 1 includes: Function identification unit 11 is used to analyze the source code using clang AST tools, identify all function definitions and record their file names and line numbers to the first file information table; Function tracing unit 12 is used to insert function tracing code at the beginning of the function body of each function definition. The function tracing code is used to obtain the function name, function input parameter pointer address and execution time point. The pointer allocation identification unit 13 is used to identify memory allocation function call points using clang AST tools and record their function name, file name and line number information to the second file information table; The pointer tracing unit 14 is used to insert pointer tracing code after each memory allocation function call. The pointer tracing code is used to obtain the pointer address, pointer type, pointer length and corresponding variable. The memory management unit 15 is used to shield the memory release interface to ensure that the memory pointer is not released during the program's lifetime and to maintain the uniqueness of the pointer address.

[0067] The functional implementation of each module in the system of the above-mentioned constructor unsigned type pointer parameter corresponds to each step in the above-mentioned method embodiment of the constructor unsigned type pointer parameter, and its functions and implementation process will not be described in detail here.

[0068] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0069] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0070] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0071] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0072] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0073] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0074] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for constructing an unsigned pointer parameter, characterized in that, Includes the following steps: Function call information and pointer allocation information are collected through code instrumentation during the pre-compilation stage; Based on the collected information, the memory structure information corresponding to the input parameters of the unsigned pointer type is determined; Construct the unsigned pointer input parameters in the unit test based on the memory structure information.

2. The method for constructing an unsigned pointer parameter as described in claim 1, characterized in that, The pre-compilation stage code instrumentation uses the clang AST tool to automatically identify function call points and memory allocation functions, and inserts tracing code at the corresponding locations.

3. The method for constructing an unsigned pointer parameter as described in claim 1, characterized in that, The steps for collecting function call information include: The clang AST tool was used to analyze the source code, identify all function definitions, and record their file names and line numbers in the first file information table. Insert function tracing code at the beginning of the function body of each function definition. The function tracing code is used to obtain the function name, the address of the function input parameter pointer, and the execution time point.

4. The method for constructing an unsigned pointer parameter as described in claim 3, characterized in that, When inserting function trace code, insert specially identified debugging information before the function trace code, and insert debugging information containing file name and line number based on the first file information table after the function trace code.

5. The method for constructing an unsigned pointer parameter as described in claim 1, characterized in that, The steps for collecting pointer allocation information include: The clang AST tool is used to identify memory allocation function call points and record their function names, file names, and line numbers in a second file information table. After each memory allocation function call, pointer tracing code is inserted. This pointer tracing code is used to obtain the pointer address, pointer type, pointer length, and corresponding variable.

6. The method for constructing an unsigned pointer parameter as described in claim 5, characterized in that, When inserting pointer trace code, insert specially identified debugging information before the pointer trace code and insert debugging information containing filenames and line numbers based on the second file information table after the pointer trace code.

7. The method for constructing an unsigned pointer parameter as described in claim 1, characterized in that, In the pre-compilation stage code instrumentation, the memory release interface is masked to ensure that the memory pointer is not released during the program's lifetime, thus maintaining the uniqueness of the pointer address.

8. The method for constructing an unsigned pointer parameter as described in claim 1, characterized in that, The process of determining the memory structure information corresponding to the input parameters of the unsigned pointer based on the collected information includes: using the address of the unsigned pointer as the key to search for the corresponding memory structure information in the pointer allocation information.

9. A system for constructor parameters of unsigned pointer type, characterized in that, Includes the following modules: The pre-compilation processing module is used for pre-compilation code instrumentation of the source code. The information gathering module is used to collect function call information and pointer allocation information through instrumentation code; The analysis module is used to determine the memory structure information corresponding to the input parameters of the unsigned pointer based on the collected information; The test case generation module is used to construct unsigned pointer input parameters in unit tests based on the memory structure information. The debugging information protection module is used to insert specially identified debugging information before and after the tracing code to maintain the integrity of the original debugging information.

10. The method for constructing an unsigned pointer parameter as described in claim 9, characterized in that, The pre-compilation processing module includes: The function identification unit is used to analyze the source code using clang AST tools, identify all function definitions, and record their file names and line numbers in the first file information table; The function tracing unit is used to insert function tracing code at the beginning of the function body of each function definition. The function tracing code is used to obtain the function name, the function input parameter pointer address and the execution time point. The pointer allocation identification unit is used to identify memory allocation function call points using clang AST tools and record their function name, file name, and line number information to the second file information table; A pointer tracing unit is used to insert pointer tracing code after each memory allocation function call. The pointer tracing code is used to obtain the pointer address, pointer type, pointer length, and corresponding variable. The memory management unit is used to shield the memory release interface to ensure that the memory pointer is not released during the program's lifetime and to maintain the uniqueness of the pointer address.

Images