Interface compatibility comparison method, device and equipment based on abstract syntax tree

Abstract

The invention discloses an interface compatibility comparison method, device and equipment based on an abstract syntax tree, and relates to the technical field of software development, and the method comprises the following steps: obtaining header files of different versions of the same software package to respectively construct AST, and extracting function nodes, variable nodes and user-defined data type nodes through preorder traversal, and recursively comparing the member number, member name, length, offset and member data type of the custom data type with the same name between the two versions, then carrying out compatibility analysis by combining variables and functions, identifying a removed or incompatible change API, and generating a report. AST is constructed through a header file, so that the dependence on a complete source code is solved, and source code level compatibility check can be performed on a third-party closed source library, a confidential component and the like; aPI difference data and ABI symbol difference data are associated and combined to generate a joint compatibility report, and compatibility can be identified from the two aspects of source code compiling and binary operation to serve as comprehensive reference for software upgrading decision making.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to an interface compatibility comparison method, apparatus, and device based on abstract syntax trees. Background Technology

[0002] In the context of the rapid development of the software industry, software updates and iterations have promoted the widespread adoption of technologies with optimized performance, higher efficiency, and enhanced security. However, this has also brought potential compatibility risks. A common compatibility risk during application software version updates is interface incompatibility. Application Programming Interfaces (APIs) are publicly available interfaces defined by software programs. Interface incompatibility can cause compilation failures and runtime errors in upper-layer applications. Ensuring the compatibility of APIs between different versions has become a critical factor affecting the successful compilation and stable operation of upper-layer applications. For foundational system software (such as operating systems and runtime libraries) represented by C programs (applications written in C), source code-level compatibility issues can cause problems such as missing function declarations and data type mismatches during the compilation phase of upper-layer applications. Changes to their APIs can lead to compilation failures, linking errors, or runtime exceptions in many applications that depend on them, resulting in significant maintenance costs and compatibility risks. Therefore, API compatibility checks can determine the extent to which a software version upgrade affects upper-layer applications that depend on it, or whether the upper-layer applications can be compiled correctly again.

[0003] Interface compatibility analysis can be conducted from a binary perspective, focusing on compiled dynamic libraries or executable files (such as ELF files) to analyze differences in the binary interfaces of applications. Alternatively, it can be based on source code, using regular expressions to extract function declarations or performing syntax analysis based on the characteristics of C programming. However, this approach only covers string parsing and comparison, making it difficult to fully handle complex C syntax variations (such as function pointers and complex macro definitions). Furthermore, this method often imposes strict input requirements, requiring the source code of the program to be scanned. This is particularly problematic when dealing with confidential software components or closed-source commercial libraries where source code is unavailable, hindering effective interface compatibility analysis and consequently preventing the analysis of the impact of interface compatibility changes on upper-layer applications. Summary of the Invention

[0004] This invention provides a method, apparatus, and device for comparing interface compatibility based on an abstract syntax tree. Using header files as the analysis object, an abstract syntax tree is constructed based on the header file source code to collect application programming interface information, thus solving the technical problem of not being able to effectively analyze interface compatibility when the source code cannot be provided.

[0005] In a first aspect, embodiments of the present invention provide an interface compatibility comparison method based on an abstract syntax tree, including:

[0006] S101: Obtain the header file sets of the first and second versions of the same software package and perform double filtering of file types to extract the header files for compatibility comparison. Based on the source code in the header files, construct the AST abstract syntax trees of the first and second versions respectively.

[0007] S102, perform a preorder traversal of the first and second versions of the AST abstract syntax tree respectively, extract function nodes, variable nodes and custom data type nodes, and generate function table, variable table and custom data type table respectively;

[0008] S103, Based on the custom data type table, recursively compare the number of members, member names, lengths, offsets, and member data types of custom data types with the same name in the first and second versions, and generate a member change type table that records the differences in custom data type members and a custom data type difference table that records all differences in data types and specific differences.

[0009] S104. Based on the custom data type difference table, combined with the variable table and function table, perform compatibility analysis, identify APIs that have been removed or have undergone incompatible changes, form an API difference list, and generate a compatibility report based on the API difference list.

[0010] Furthermore, the method also includes:

[0011] Obtain the dynamic library files of the first and second versions of the same software package and perform ABI difference analysis to obtain a list of ABI symbol differences;

[0012] Based on the symbol names in the ABI symbol difference list, the API difference list is associated with the ABI symbol difference list to generate a joint compatibility report that includes source code level differences and binary level differences.

[0013] Furthermore, S101 includes:

[0014] Retrieve the header file sets for both version 1 and version 2 of the same software package;

[0015] Perform double filtering on file types in the header file set. First, extract files with the .h extension, and then extract files with the MIME type value of text / xc from them to form a header file for compatibility comparison.

[0016] Based on compatibility comparisons, the header files are compiled to generate the first and second versions of the Abstract Syntax Tree (AST).

[0017] Furthermore, S102 includes:

[0018] Perform a preorder traversal of the first and second versions of the AST (Abstract Syntax Tree) to extract the name, position, and length attributes of function nodes, variable nodes, and custom data type nodes.

[0019] Based on the function name of the function node as the key, each function value includes the function name, function prototype, return value type, formal parameter list, parameter types, and function declaration file name, forming a function table;

[0020] Based on the variable name of the variable node as the key, each variable value includes the variable name, variable type, and variable declaration file name, forming a variable table;

[0021] Based on the structure name in the custom data type node as the key, and each structure value including the structure member list, member type, member length, and member offset, a custom data type table is formed.

[0022] Furthermore, S103 includes:

[0023] The first-level search compares the differences in the fields of member quantity, member name, member length, member offset, and member type for custom data types with the same name in the first and second versions. Members with differences are marked as having changed member types and the specific differences are recorded, generating a member change type table.

[0024] The second-level search involves marking non-basic data types whose member types have been marked as changed as changed, marking the entire custom data type to which the member belongs as changed, generating a custom data type difference table, and recording the members with differences and the specific difference items.

[0025] Iteratively execute the first-level search and the second-level search until no new change types are added, and obtain the final custom data type difference table.

[0026] Furthermore, S104 includes:

[0027] Based on the custom data type difference table and the variable table, if the data type of the variable is a basic data type, then a string comparison is performed directly; if the data type of the variable is a custom type, then the variable change is identified by querying the custom data type difference table and variable change information is generated.

[0028] Based on the custom data type difference table and the function table, identify the differences in function name, return type or parameter list in function signature. If the function parameter or return type is a custom type, identify the function change by querying the custom data type difference table and generate function change information.

[0029] Based on variable change information, function change information, and custom data type difference table, an API difference list is generated, and a compatibility report is produced.

[0030] Furthermore, the compatibility report includes structured data in JSON format and a visualization page in HTML format.

[0031] Secondly, embodiments of the present invention provide an interface compatibility comparison device based on an abstract syntax tree, comprising:

[0032] The Abstract Syntax Tree (AST) building module is used to obtain the header file sets of the first and second versions of the same software package and perform double filtering extraction. Then, based on the source code implementation in the header files, the first and second versions of the AST are built respectively.

[0033] The Abstract Syntax Tree Traversal module is used to perform preorder traversal of the first and second versions of the Abstract Syntax Tree (AST) respectively, extract function nodes, variable nodes, and custom data type nodes, and generate function tables, variable tables, and custom data type tables respectively.

[0034] The data type comparison module is used to recursively compare the differences between custom data types with the same name in the first and second versions based on the custom data type table, and generate a custom data type difference table and a member change type table.

[0035] The Interface Difference Comparison module is used to perform compatibility analysis based on a custom data type difference table, combined with a variable table and a function table. It identifies APIs that have been removed or have undergone incompatible changes, generates an API difference list, and produces a compatibility report based on the API difference list.

[0036] Thirdly, embodiments of the present invention provide an electronic device, including:

[0037] One or more processors;

[0038] Storage device for storing one or more programs.

[0039] When the one or more programs are executed by the one or more processors, the one or more processors implement the above-described interface compatibility comparison method based on abstract syntax trees.

[0040] Fourthly, embodiments of the present invention provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the aforementioned interface compatibility comparison method based on an abstract syntax tree.

[0041] This invention provides a method, apparatus, device, and medium for interface compatibility comparison based on abstract syntax trees (ASTs). The method extracts header files for compatibility comparison from a collection of header files from different versions of the same software package. It then constructs different versions of ASTs and performs a preorder traversal to form function tables, variable tables, and custom data type tables. First, it identifies changes in the members of custom data types between different versions to form a custom data type difference table. Then, it combines the function and variable tables to identify APIs that have undergone incompatible changes or removals, forming an API difference list and outputting a compatibility report. Finally, it associates this with ABI symbol difference lists from different versions of dynamic library files through ABI parsing to generate a joint compatibility report containing both source code-level and binary-level differences. By using header files as input and constructing an AST for parsing, the strong dependence on complete source code is overcome, enabling source code-level compatibility checks on third-party closed-source libraries and confidential components. API difference data is then correlated and merged with ABI symbol difference data to generate a unified joint compatibility report. Developers and operations personnel can interpret and prevent compatibility issues from both the source code compilation and binary execution levels, analyzing the impact of interface compatibility changes on upper-layer applications, providing a comprehensive reference for software upgrade decisions. The compatibility report is also output in JSON and HTML formats, facilitating secondary data development and intuitive, rapid visualization. Attached Figure Description

[0042] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0043] Figure 1 This is a flowchart of an interface compatibility comparison method based on an abstract syntax tree, as described in Embodiment 1 of the present invention.

[0044] Figure 2 This is a flowchart of an interface compatibility comparison method based on an abstract syntax tree, as described in Embodiment 2 of the present invention.

[0045] Figure 3 This is a schematic diagram of the AST abstract syntax tree described in Embodiment 2 of the present invention;

[0046] Figure 4 This is a flowchart of an interface compatibility comparison method based on an abstract syntax tree, as described in Embodiment 3 of the present invention.

[0047] Figure 5 This is a schematic diagram of the structure of an interface compatibility comparison device based on an abstract syntax tree as described in Embodiment 4 of the present invention;

[0048] Figure 6 This is a structural diagram of the electronic device described in Embodiment 5 of the present invention. Detailed Implementation

[0049] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0050] C programs, such as operating systems and runtime libraries, provide interfaces that many upper-level applications depend on. Interface incompatibility can lead to issues like missing function declarations and data type mismatches. API changes can cause compilation failures, linking errors, or runtime exceptions in many dependent upper-level applications. Therefore, API compatibility analysis is necessary between different versions of the same C program. However, existing analysis methods rely heavily on the complete source code, which is particularly problematic in certain limited scenarios where the source code is unavailable. Alternatively, current techniques use regular expressions to parse interface declarations in the source file before comparison, resulting in inaccurate and incomplete analysis of actual compatibility issues. Therefore, effective API compatibility analysis is urgently needed when the complete source code is unavailable, covering compile-time compatibility risks. The following solution is provided:

[0051] Example 1

[0052] Figure 1 The interface compatibility comparison method based on abstract syntax trees, as described in Embodiment 1 of this invention, constructs abstract syntax trees (ASTs) using header files from different versions of the same software package, extracts function nodes, variable nodes, and custom data type nodes, recursively compares the differences in members of custom data types, and then combines the differences in variables and functions to form an API difference list and generate a compatibility report. The specific steps include:

[0053] S101: Obtain the header file sets of the first and second versions of the same software package, perform double filtering of file types to extract the header files for compatibility comparison, and construct the AST abstract syntax trees of the first and second versions respectively based on the source code in the header files.

[0054] To address situations where complete source code is unavailable, we can obtain only a collection of header files from different versions of the same software package, extract the useful header files, and use the information contained within them as input to parse the API. First, we extract two different versions of the header files for the same target software package from the package management system. Then, we perform double filtering on these header files using file extensions and MIME type values ​​to extract the header files needed for compatibility comparison, forming compatibility comparison header files. Next, we compile based on these compatibility comparison header files, constructing two different versions of the Abstract Syntax Tree (AST) using the header file code. By traversing these ASTs, we can obtain the contents of functions, variables, and custom data, and compare and analyze the API differences between the two versions.

[0055] S102, perform a preorder traversal of the first and second versions of the AST abstract syntax tree respectively, extract function nodes, variable nodes and custom data type nodes, and generate function table, variable table and custom data type table respectively.

[0056] A pre-order traversal algorithm is employed, visiting the root node first and then recursively visiting child nodes in the Abstract Syntax Tree (AST). During the traversal, specific node types such as function nodes, variable nodes, and custom data types are identified. Parameters and fields are extracted from each type of node, and a function table, a variable table, and a custom data type table are constructed based on the extracted function node information, variable node information, and custom data type information, respectively. The extracted data is stored in key-value pairs: function tables use function names as keys, variable tables use variable names as keys, and custom data type tables use data type names (such as structure names or enumeration names) as keys. All tables can be saved as JSON files.

[0057] S103. Based on the custom data type table, recursively compare the number of members, member names, lengths, offsets, and member data types of custom data types with the same name in the first and second versions, and generate a member change type table that records the differences between custom data type members and a custom data type difference table that records all differences in data types and specific differences.

[0058] First, the two versions of the custom data type table are compared, performing a recursive comparison for custom data types with the same name. For example, the custom data type could be "struct foo". The comparison first examines the differences between the two versions in the number of members, member names, member lengths (e.g., sizeof values), and member offsets (e.g., offset values). Simultaneously, it considers whether the member data type is a basic data type and compares differences between members of the same data type. When a difference is found, the member is marked as changed, and the specific difference for that member is recorded, resulting in a member change type table. If a member of the structure has already been marked as changed, the entire custom data type to which that member belongs is marked as changed, resulting in a custom data type difference table.

[0059] S104. Based on the custom data type difference table, combined with the variable table and function table, perform compatibility analysis, identify APIs that have been removed or have undergone incompatible changes, form an API difference list, and generate a compatibility report based on the API difference list.

[0060] First, compatibility analysis is performed based on the custom data type difference table, combined with the variable table and function table. For the variable table, if the variable's data type is a basic data type, the variable declaration strings of the two versions are directly compared; if a change exists, the variable is considered incompatible. If the variable's data type is a non-basic data type or a custom type, the custom data type difference table is queried; if the data type is marked as changed in the table, the variable is considered incompatible. For the function table, the three elements in the function signature are compared; if any one of these elements changes, the function is considered incompatible. If the function's parameter or return value type is a custom data type, the custom data type difference table is queried; if the data type is marked as changed in the table, the function is considered incompatible. It is also necessary to check if a function or variable existed in one version but was removed in another; if this occurs, the changed function or variable must be considered incompatible. A list of APIs with incompatible changes is created, and a compatibility report is generated based on this list.

[0061] Optionally, the method further includes: obtaining the dynamic library files of the first and second versions of the same software package and performing ABI difference analysis to obtain an ABI symbol difference list.

[0062] While analyzing API differences using header files, you can also obtain different versions of dynamic library files (such as .so files) from the same software package and use ABI analysis tools (such as abi-compliance-checker) to perform symbol-level difference analysis on the dynamic library files to obtain an ABI symbol difference list.

[0063] Based on the symbol names in the ABI symbol difference list, the API difference list is associated with the ABI symbol difference list to generate a joint compatibility report that includes source code level differences and binary level differences.

[0064] The ABI symbol difference list is associated with the API difference list based on symbol names in the ABI symbol difference list. For each symbol, the joint compatibility report displays compatibility conclusions at both the API and ABI levels (e.g., "Function foo: API compatible but ABI incompatible"). The joint compatibility report is also output in JSON and HTML formats, providing a full-chain compatibility assessment from compilation to runtime. For example, functions and variables with the same names in the API difference list are associated with the ABI symbol difference list; for instance, data from the API difference list includes:

[0065] If the ABI symbol difference list contains the data foo:{"func_def":"xxx","change_type":"same"...}, then the two sets of data will be associated and merged to generate the new data.

[0066] The statement `“foo”:{“func_def”:“xxx”,“abi_change_type”:“removed”,“api_changed_type”:“same”,“xxx”}` contains compatibility conclusions for the same function `foo` at both the source code and binary levels, recorded in the joint compatibility report. ABI analysis can uncover incompatibility issues at the runtime linking and symbol lookup levels. An API that undergoes incompatible changes at the source code level may exhibit different symbolic characteristics at the binary level due to compiler optimizations, and its compilation errors cannot be detected during the binary analysis phase. Therefore, ABI compatibility analysis cannot provide early risk warnings for upper-level application developers during the compilation phase. Combining the binary-level ABI compatibility analysis conclusions with the source code-level API compatibility analysis conclusions allows for the assessment of compatibility risks across the entire software iteration process, from compilation to runtime.

[0067] Optionally, the compatibility report includes structured data in JSON format and a visualization page in HTML format.

[0068] To ensure the compatibility report presents comprehensive data, improves data usability for secondary development, and facilitates user observation and analysis, the compatibility report is stored as both structured data in JSON format and a visual page in HTML format. Developers and operations personnel can use the JSON-formatted structured data to write subsequent programs based on all the differences, making it easy for machines to read and process. Ordinary users can easily and quickly identify API incompatibility issues and select the appropriate software package version using the HTML-formatted visual page.

[0069] This embodiment extracts header files for compatibility comparison from a collection of header files from different versions of the same software package. It then constructs different versions of the Abstract Syntax Tree (AST) and performs a preorder traversal of the AST to form function tables, variable tables, and custom data type tables. First, it identifies changes in member types of the custom data type tables between different versions to form a custom data type difference table. Then, it combines the function and variable tables to identify APIs that have undergone incompatible changes or removals, forming an API difference list and outputting a compatibility report. Finally, it associates this with the ABI symbol difference list obtained from ABI parsing of different versions of dynamic library files to generate a joint compatibility report containing both source code-level and binary-level differences. By using header files as input and constructing an AST for parsing, no additional tools are required, breaking the strong dependence on complete source code. It can perform source code-level compatibility checks on third-party closed-source libraries and confidential components, and has cross-platform applicability. It supports checking API differences during the iteration process of C program versions under different compilers or operating system environments. Then, the API difference data is correlated and merged with ABI symbol difference data to generate a unified joint compatibility report. Developers and operations personnel can interpret and prevent compatibility from both the source code compilation and binary execution levels, analyze the impact of interface compatibility changes on upper-layer applications, and provide a comprehensive reference for software upgrade decisions. Moreover, no code execution is required, which facilitates tight integration with existing build systems and toolchains (such as Makefile, CMake, GCC, etc.). The compatibility report is also output in JSON and HTML formats, which facilitates secondary development and utilization of data and intuitive and fast visualization.

[0070] Example 2

[0071] Figure 2 This is a flowchart of an interface compatibility comparison method based on an abstract syntax tree, as described in Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment. In this embodiment, S101 is specifically optimized as follows:

[0072] Retrieve the header file sets for both version 1 and version 2 of the same software package;

[0073] Perform double filtering on file types in the header file set. First, extract files with the .h extension, and then extract files with the MIME type value of text / xc from them to form a header file for compatibility comparison.

[0074] Based on compatibility comparisons, the header files are compiled to generate the first and second versions of the Abstract Syntax Tree (AST).

[0075] Accordingly, the interface compatibility comparison method based on abstract syntax trees provided in this embodiment specifically includes:

[0076] S201, retrieves the header file set for the first and second versions of the same software package.

[0077] The header file set of a software package can be obtained from the file list of a software repository (such as a Git repository or an RPM package). File system scanning tools (such as the `find` command) can be used to collect the header file sets of different versions of the same software package. It's important to note that although header files do not declare all the interfaces implemented by a program (e.g., a C program), the interfaces declared in header files are all externally visible (i.e., APIs, Application Programming Interfaces). Other programs often only receive this part of the information and can only rely on these visible APIs for development. Therefore, by analyzing the compatibility of these visible interfaces in header files, the impact of API changes on upper-layer applications can be identified.

[0078] S202 performs dual filtering of file types in the header file set. First, it extracts files with the extension .h, and then it extracts files with the MIME type value of text / xc from them to form a header file for compatibility comparison.

[0079] Within the header file set, a two-layer file type filtering process is employed. The first layer filters out all .h files by matching file extensions using the regular expression .*\.h$. A second layer of filtering is then applied: the MIME type of each .h file is read using the `file` command or Python's `mimetypes` library, retaining only files with the MIME type `text / xc` to ensure they are C language header files, excluding other file types, thus creating a compatibility comparison header file set.

[0080] S203, based on compatibility comparison, uses header files to compile and generate the first and second versions of the AST (Abstract Syntax Tree).

[0081] By calling the tool's programming interface, specifying the C language standard and header file search paths, the header file source code is converted into an abstract syntax tree (AST). When there are inclusion relationships between header files, multiple header files can be converted into a unified AST. For example, calling the Python binding library interface of the Clang tool (e.g., the `clang.cindex` module) to create an AST parser (e.g., `clang.cindex.Index.create()`), setting compilation parameters (e.g., `-std=c99-I / usr / include`) to specify the C language standard as c99 and the header file search paths (including system header file paths and package-defined paths), and calling the `parse` method to convert the filtered header file source code into an AST. During AST construction, if there are inclusion relationships between header files (e.g., `#include` directives), Clang automatically handles header file inclusion relationships and resolves these dependencies. When there are dependencies between header files, multiple header files can be merged into a unified AST representation. For example, when the header file `ah` includes `bh`, the AST will contain the node trees of both files, ensuring correct dependency resolution and the integrity of the syntax tree. The resulting AST is shown below. Figure 3 As shown.

[0082] S204 performs a preorder traversal of the first and second versions of the AST (Abstract Syntax Tree), extracts function nodes, variable nodes, and custom data type nodes, and generates function tables, variable tables, and custom data type tables, respectively.

[0083] Since existing analysis methods based on abstract syntax trees are mainly designed for object-oriented languages ​​such as Java, and focus on interface models such as classes and inheritance, as well as compatibility rules such as access control modifier changes, they are fundamentally different from C, a procedural programming language with functions and data structures at its core. Therefore, existing implementation techniques cannot be directly applied to the abstract syntax tree of C.

[0084] Specifically, the first and second versions of the AST (Abstract Syntax Tree) are preorder traversed to extract the name, position, and length attributes of function nodes, variable nodes, and custom data type nodes.

[0085] Tools (such as Clang's AST visitor pattern: clang.cindex.CursorVisitor) can be used to traverse all nodes in different versions of the AST, starting from the root node and proceeding in preorder traversal, first the parent nodes and then the child nodes. For each node, its type (cursor.kind) is checked: if the node type is a function node (CXCursor_FunctionDecl), the function information is extracted: name, return type, parameters, etc.; if the node type is a variable node (CXCursor_VarDecl), the variable information is extracted: name, type, etc.; if the node type is a custom data type (struct type CXCursor_StructDecl, enumeration type CXCursor_EnumDecl, or array, etc.), the custom data type information is extracted: name, members, etc.

[0086] Based on the function name as the key, each function value includes the function name, function prototype, return type, parameter list, parameter types, and function declaration file name, forming a function table. For example, a function table is formed using the function name as the key and a dictionary containing the function prototype string `function_prototype`, the return type `return_type`, the parameter list `parameters` (each parameter includes type and name), and the declaration file name `file`, etc.

[0087] Based on the variable name as the key, each variable value includes the variable name, variable type, and variable declaration file name, forming a variable table. For example, a variable table is formed with the variable name as the key and a dictionary containing variable type (variable_type), declaration file name (file), etc., as the value.

[0088] Based on the structure name in the custom data type node as the key, and each structure value including the structure member list, member type and member offset, a custom data type table is formed.

[0089] For example, a structure data type table can be formed using the data type name as the key. For instance, if the custom data type is a struct, the struct name would be the key, and the values ​​would be dictionaries containing a list of members, the declaration file name, etc. Each member would also include the member name, member type, member length, and member offset. If the custom data type is an enumeration, the enumeration name would be the key, and the values ​​would be dictionaries containing enumeration members, enumeration values, the declaration file name, etc., forming an enumeration data type table. All tables can be managed using Python dictionaries and output as a JSON file (e.g., function_table_v1.json).

[0090] S205, based on the custom data type table, recursively compare the number of members, member names, lengths, offsets, and member data types of custom data types with the same name in the first and second versions, and generate a member change type table that records the differences between custom data type members and a custom data type difference table that records all differences in data types and specific differences.

[0091] S206. Based on the custom data type difference table, combined with the variable table and function table, perform compatibility analysis to identify APIs that have been removed or have undergone incompatible changes, form an API difference list, and generate a compatibility report based on the API difference list.

[0092] This embodiment uses a dual filtering rule based on file extension and MIME type to accurately select the C language header files truly used for C program API compatibility analysis. This effectively eliminates interference from non-C language files or binary files with the same file extension, ensuring the accuracy of the input data for subsequent AST construction and analysis. By traversing the AST in preorder and extracting node information by category, it generates clearly structured and information-rich function tables, variable tables, and custom data type tables. The key-value pair table structure fully captures the key attributes of the interface, providing a solid data foundation for subsequent difference comparisons. Through a clear header file processing flow and AST traversal rules, it reduces sensitivity to specific project structures or coding styles, making it applicable to C language projects of different sizes and styles, ensuring consistency in the analysis process and repeatability of the results.

[0093] Example 3

[0094] Figure 4 This is a flowchart of an interface compatibility comparison method based on an abstract syntax tree as described in Embodiment 3 of the present invention. This embodiment is an optimization based on the above embodiment. In this embodiment, S103 is specifically optimized as follows:

[0095] The first-level search compares the differences in the fields of member quantity, member name, member length, member offset, and member type for custom data types with the same name in the first and second versions. Members with differences are marked as having changed member types and the specific differences are recorded, generating a member change type table.

[0096] The second-level search involves marking non-basic data types whose member types have been marked as changed as changed, marking the entire custom data type to which the member belongs as changed, generating a custom data type difference table, and recording the members with differences and the specific difference items.

[0097] Iteratively execute the first-level search and the second-level search until no new change types are added, and obtain the final custom data type difference table.

[0098] Accordingly, the interface compatibility comparison method based on abstract syntax trees provided in this embodiment specifically includes:

[0099] S301: Obtain the header file sets of the first and second versions of the same software package, perform double filtering of file types to extract the header files for compatibility comparison, and construct the AST abstract syntax trees of the first and second versions respectively based on the source code in the header files.

[0100] S302, perform a preorder traversal of the first and second versions of the AST abstract syntax tree respectively, extract function nodes, variable nodes and custom data type nodes, and generate function tables, variable tables and custom data type tables respectively.

[0101] S303, Level 1 search: Under the same custom data type in the first and second versions, compare the differences in the fields of member quantity, member name, member length, member offset, and member type. Mark the members with differences as members whose types have changed and record the specific differences, generating a member change type table.

[0102] First, the custom data type table is traversed across different versions to identify changes to the custom data types. For each custom data type with the same name between two versions, such as a struct called `Point`, its member list is compared to check if the number of members is consistent. If not, the struct data type is marked as changed, and the difference is recorded (e.g., the number of members changes from 3 to 2). Then, for each member under this struct, its member name, member type, member length (calculated using `sizeof`), and member offset (calculated using `offset`) are compared. If the member's data type is a basic data type (e.g., `int`, `float`), its string representation is directly compared. If the member's data type is a non-basic type (e.g., a nested struct `Bar`), type comparison is skipped, and only changes in member length and offset are compared. If member attributes are inconsistent (e.g., inconsistent basic data types or inconsistent member length and offset in the custom data type), the member is marked as changed, recorded, and a member change type table is created. The member change type table records the changes to each member under each custom data type, such as "the offset of member A changes from 0 to 4".

[0103] S304, Second-level search: For non-basic data types whose member types have been marked as changed, mark the entire custom data type to which the member belongs as changed, generate a custom data type difference table, and record the members with differences and the specific difference items.

[0104] After the member change search, it is also necessary to compare the changes of the custom data types. Based on the results of the first-level search, the members of the non-basic data types under each custom data type are recursively checked. If the data type of a member B has been marked as changed in the member change type table, then the overall custom data type to which member B belongs will also be marked as changed and recorded to form a custom data type difference table.

[0105] S305, iteratively execute the first-level search and the second-level search until no new change types are added, and obtain the final custom data type difference table.

[0106] By setting up an iterative loop, the first and second level searches are performed in each iteration until no new change types are added in a single iteration (this can be determined by comparing the size of the member change type table before and after the iteration). The final custom data type difference table is then determined. This table contains all changed custom data types, as well as the difference data members at all levels and their specific descriptions.

[0107] S306: Based on the custom data type difference table, combined with the variable table and function table, perform compatibility analysis to identify APIs that have been removed or have undergone incompatible changes, form an API difference list, and generate a compatibility report based on the API difference list.

[0108] An optional implementation of this embodiment is as follows: based on the custom data type difference table and the variable table, if the data type of the variable is a basic data type, then a string comparison is performed directly; if the data type of the variable is a custom type, then the variable change is identified by querying the custom data type difference table, and variable change information is generated.

[0109] First, the variable table is traversed. For each variable in the table: if a variable exists in only one version, it is marked as "removed"; if a variable exists in both versions, its data type is checked: if it is a basic data type (such as integer (int), floating-point type (float), character type (char), void, etc.), its strings are directly compared; if it is a user-defined data type (such as structure, enumeration, etc.), the user-defined data type difference table is queried. If the data type has been marked as changed in the user-defined data type difference table, the variable is marked as "incompatible change," and variable change information is generated. For example, if a variable is declared as `struct foo var`, and the data type `foo` is recorded in the change type table, then the variable `var` has undergone an incompatible change.

[0110] Based on the custom data type difference table and the function table, the differences in function name, return type, or parameter list in the function signature are identified. If the function parameter or return type is a custom type, the function change is identified by querying the custom data type difference table and function change information is generated.

[0111] First, the function table is traversed. For each function in the table: if a function exists in only one version, it is marked as "removed"; if a function exists in both versions, the function signatures are compared: the function names are directly compared as strings; if the return type is a basic data type, it is directly compared; if it is a custom data type, the member change type table is queried; the parameter list needs to be compared in terms of the number of parameters and the type of each parameter. If they are basic data types, they are directly compared; if they are custom data types, the custom data type difference table is queried; if any of the function name, return type, or parameter list has changed, or if the custom data type of the parameters or return value has been marked as changed, the function is marked as "incompatible change," and function change information is generated. For example, if a function is declared as func(struct bar b), and the data type bar is recorded in the change type table, then the function func has undergone an incompatible change.

[0112] Based on variable change information, function change information, and custom data type difference table, an API difference list is generated, and a compatibility report is produced.

[0113] By combining variable change information, function change information, and custom data type difference tables, an API difference list is formed. The API difference list includes all API items that have been "removed" and "incompatible changes". When the generated compatibility report is output in JSON format, it contains detailed information for each API (such as name, change type, and difference description). When output in HTML format, it can be generated using a template engine (such as Jinja2) and can be displayed prominently using color tables and different colors to highlight different change types.

[0114] This embodiment employs a recursive comparison algorithm combining first-level and second-level searches, and introduces an iterative mechanism. This allows for precise identification of changes within custom data types (such as structs), as well as cascading change effects caused by nesting and circular dependencies. It solves the problem that regular expressions or shallow comparisons cannot handle internal changes in complex data structures, improving the depth and accuracy of API compatibility analysis. By generating a member change type table and a custom data type difference table, it records whether a change has occurred, and details the specific members affected, the changed attributes (such as offset and length), and the change propagation path. This enables development and operations personnel to quickly locate compatibility issues and simplifies debugging and adaptation work. When comparing the compatibility of functions and variables, by querying the custom data type difference table, when the underlying data type on which the function signature or variable type depends undergoes internal changes, it accurately identifies these as incompatible changes, forming a complete change impact propagation chain and effectively preventing the underreporting of important compatibility issues.

[0115] Example 4

[0116] Figure 5 This is a schematic diagram of an interface compatibility comparison device based on an abstract syntax tree according to Embodiment 4 of the present invention. In this embodiment, the interface compatibility comparison device based on an abstract syntax tree includes:

[0117] Abstract Syntax Tree (AST) building module 810 is used to obtain the header file sets of the first and second versions of the same software package and perform double filtering extraction. Then, based on the source code implementation in the header files, it constructs the first and second versions of the AST abstract syntax tree respectively.

[0118] Abstract Syntax Tree Traversal Module 820 is used to perform preorder traversal of the first and second versions of the AST abstract syntax tree respectively, extract function nodes, variable nodes and custom data type nodes, and generate function table, variable table and custom data type table respectively;

[0119] The data type comparison module 830 is used to recursively compare the differences of custom data types with the same name in the first and second versions based on the custom data type table, and generate a member change type table and a custom data type difference table.

[0120] The Interface Difference Comparison Module 840 is used to perform compatibility analysis based on a custom data type difference table, combined with a variable table and a function table, to identify APIs that have been removed or have undergone incompatible changes, form an API difference list, and generate a compatibility report based on the API difference list.

[0121] This embodiment uses an Abstract Syntax Tree (AST) construction module to obtain header file sets from different versions of the same software package, filters and extracts the required header files, and constructs ASTs for each. An AST traversal module performs a pre-order traversal on the ASTs of different versions to extract information from various nodes, generating function tables, variable tables, and custom data types. A data type comparison module recursively compares the differences in custom data types with the same names between two versions based on the custom data type table. An interface difference comparison module identifies APIs that have been removed or have undergone incompatible changes based on custom data type differences, combined with the variable and function tables, forming an API difference list and generating a compatibility report. By using header files as input and constructing and parsing the AST, this approach overcomes the strong dependence on complete source code, enabling source code-level compatibility checks on third-party closed-source libraries and confidential components. Then, the API difference data is correlated and merged with ABI symbol difference data to generate a unified joint compatibility report. Developers and operations personnel can interpret and prevent compatibility issues from both the source code compilation and binary execution levels, analyzing the impact of interface compatibility changes on upper-layer applications, providing a comprehensive reference for software upgrade decisions. The compatibility report is also output in JSON and HTML formats, facilitating secondary data development and intuitive, rapid visualization.

[0122] The interface compatibility comparison device based on abstract syntax tree provided in this embodiment of the invention can execute the interface compatibility comparison method based on abstract syntax tree provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0123] Example 5

[0124] Figure 6 This is a structural diagram of an electronic device according to Embodiment 5 of the present invention. Figure 6 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 6 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0125] like Figure 6 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0126] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0127] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0128] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 6 Not shown; usually referred to as a "hard drive"). Although Figure 6 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0129] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0130] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 6 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 6 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0131] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the interface compatibility comparison method based on abstract syntax tree provided in the embodiments of the present invention.

[0132] Example 6

[0133] Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the interface compatibility comparison method based on the abstract syntax tree provided in the above embodiments.

[0134] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0135] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0136] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0137] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0138] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for comparing interface compatibility based on abstract syntax trees, characterized in that, include: S101: Obtain the header file sets of the first and second versions of the same software package, perform double filtering of file types to extract the header files for compatibility comparison, and construct the AST abstract syntax trees of the first and second versions respectively based on the source code of the header files; S102, perform a preorder traversal of the first and second versions of the AST abstract syntax tree respectively, extract function nodes, variable nodes and custom data type nodes, and generate function table, variable table and custom data type table respectively; S103, Based on the custom data type table, recursively compare the number of members, member names, lengths, offsets, and member data types of custom data types with the same name in the first and second versions, and generate a member change type table that records the differences in custom data type members and a custom data type difference table that records all differences in data types and specific differences. S104. Based on the custom data type difference table, combined with the variable table and function table, perform compatibility analysis, identify APIs that have been removed or have undergone incompatible changes, form an API difference list, and generate a compatibility report based on the API difference list.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the dynamic library files of the first and second versions of the same software package and perform ABI difference analysis to obtain a list of ABI symbol differences; Based on the symbol names in the ABI symbol difference list, the API difference list is associated with the ABI symbol difference list to generate a joint compatibility report that includes source code level differences and binary level differences.

3. The method according to claim 1, characterized in that, S101 includes: Retrieve the header file sets for both version 1 and version 2 of the same software package; Perform double filtering on file types in the header file set. First, extract files with the .h extension, and then extract files with the MIME type value of text / xc from them to form a header file for compatibility comparison. Based on compatibility comparisons, the header files are compiled to generate the first and second versions of the Abstract Syntax Tree (AST).

4. The method according to claim 1, characterized in that, S102 includes: Perform a preorder traversal of the first and second versions of the AST (Abstract Syntax Tree) to extract the name, position, and length attributes of function nodes, variable nodes, and custom data type nodes. Based on the function name of the function node as the key, each function value includes the function name, function prototype, return value type, formal parameter list, parameter types, and function declaration file name, forming a function table; Based on the variable name of the variable node as the key, each variable value includes the variable name, variable type, and variable declaration file name, forming a variable table; Based on the structure name in the custom data type node as the key, and each structure value including the structure member list, member type, member length, and member offset, a custom data type table is formed.

5. The method according to claim 1, characterized in that, S103 includes: The first-level search compares the differences in the fields of member quantity, member name, member length, member offset, and member type for custom data types with the same name in the first and second versions. Members with differences are marked as having changed member types and the specific differences are recorded, generating a member change type table. The second-level search involves marking non-basic data types whose member types have been marked as changed as changed, marking the entire custom data type to which the member belongs as changed, generating a custom data type difference table, and recording the members with differences and the specific difference items. Iteratively execute the first-level search and the second-level search until no new change types are added, and obtain the final custom data type difference table.

6. The method according to claim 1, characterized in that, S104 includes: Based on the custom data type difference table and the variable table, if the data type of the variable is a basic data type, then a string comparison is performed directly; if the data type of the variable is a custom type, then the variable change is identified by querying the custom data type difference table and variable change information is generated. Based on the custom data type difference table and the function table, identify the differences in function name, return type or parameter list in function signature. If the function parameter or return type is a custom type, identify the function change by querying the custom data type difference table and generate function change information. Based on variable change information, function change information, and custom data type difference table, an API difference list is generated, and a compatibility report is produced.

7. The method according to claim 1, characterized in that, The compatibility report includes structured data in JSON format and a visualization page in HTML format.

8. An interface compatibility comparison device based on abstract syntax trees, characterized in that, include: The Abstract Syntax Tree (AST) building module is used to obtain the header file sets of the first and second versions of the same software package and perform double filtering extraction. Then, it constructs the first and second versions of the AST based on the source code in the header files. The Abstract Syntax Tree Traversal module is used to perform preorder traversal of the first and second versions of the Abstract Syntax Tree (AST) respectively, extract function nodes, variable nodes, and custom data type nodes, and generate function tables, variable tables, and custom data type tables respectively. The data type comparison module is used to recursively compare the differences between custom data types with the same name in the first and second versions based on the custom data type table, and generate a member change type table and a custom data type difference table. The Interface Difference Comparison module is used to perform compatibility analysis based on a custom data type difference table, combined with a variable table and a function table. It identifies APIs that have been removed or have undergone incompatible changes, generates an API difference list, and produces a compatibility report based on the API difference list.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the interface compatibility comparison method based on the abstract syntax tree as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the AST-based interface compatibility comparison method as described in any of the abstract syntax trees.

Images