CN114329492A - Vulnerability detection method for Go language chain code - Google Patents
Vulnerability detection method for Go language chain code Download PDFInfo
- Publication number
- CN114329492A CN114329492A CN202111654617.1A CN202111654617A CN114329492A CN 114329492 A CN114329492 A CN 114329492A CN 202111654617 A CN202111654617 A CN 202111654617A CN 114329492 A CN114329492 A CN 114329492A
- Authority
- CN
- China
- Prior art keywords
- vulnerability
- chain code
- detection
- chain
- exists
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
The invention provides a vulnerability detection method for Go language chain codes, and relates to the technical field of information security. Firstly, before a chain code development stage or deployment, obtaining static structure characteristics of a chain code by analyzing an abstract syntax tree of a Go language chain code; then extracting and abstracting static structure characteristics of chain code security vulnerabilities, and compiling corresponding vulnerability detection rules aiming at the structure characteristics of each vulnerability; then applying a group of vulnerability detection rules to carry out feature matching of vulnerabilities, and if matching is successful, considering that corresponding security vulnerabilities exist in the chain codes; and finally, according to a predefined output format, outputting the brief description of the detected vulnerability in the chain code and the position of the vulnerability in the chain code to the user interface, and counting the detection result. The method can effectively locate the loopholes existing in the chain codes and has outstanding speed advantage compared with a Go language detection tool.
Description
Technical Field
The invention relates to the technical field of information security, in particular to a vulnerability detection method for Go language chain codes.
Background
Compared with the traditional application program, the security problem of the intelligent contract mainly has the following two differences:
on the one hand, legacy applications can fix and release new versions in time after discovering errors, but smart contracts are irreversible and immutable, which is determined by consensus mechanisms at the bottom of the blockchain. No matter how popular or how much funds it holds, intelligent contracts with holes cannot be repaired. Therefore, it is important to strictly verify the correctness and security of the intelligent contract before deployment, which puts high demands on the analysis tool of the intelligent contract.
On the other hand, although smart contracts are generally referred to as chain codes on a Fabric platform, unlike smart contracts for an ethernet platform written in a Domain Specific Language (DSL), chain codes for a Fabric platform are developed in a general programming Language (Go, Java, node. This greatly reduces the developer's admission thresholds, can reduce learning costs and attract more developers, and supports the use of reliable existing tools and libraries from these communities. However, due to the lack of specific limitations and functions for blockchain characteristics and the immaturity of development specifications, most developers tend to bound chain code to common applications, neglect differences caused by the specific operating environment of the chain code, and introduce potential security holes in the development of the chain code.
At present, the safety problem of intelligent contracts is outstanding, related research works are mainly focused on an Ethernet platform, and few safety research works aiming at Fabric chain codes are carried out. While general purpose programming languages typically have their own detection tools to improve code quality, such as govet and golint for the Go language, they are typically used to detect syntax errors in conventional development and do not effectively identify security issues related to chain code characteristics. Relevant researchers have detailed 14 security risks related to uncertainty and design specifications in chain codes and designed a static detection tool based on the Go language abstract syntax tree to identify these risks, but the tool is not open source. At present, a vulnerability detection scheme aiming at the Fabric chain code is lacked in the market.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: in view of the above deficiencies of the prior art, a vulnerability detection method for Go language chain codes is provided to identify security vulnerabilities in chain codes. The method can be applied to the development and deployment phases of the chain codes and helps developers to realize safer chain codes.
In order to solve the technical problems, the technical scheme adopted by the invention is as follows: a vulnerability detection method aiming at Go language chain codes comprises the steps of firstly, obtaining static structure characteristics of the chain codes by analyzing an abstract syntax tree of the Go language chain codes at the development stage or before deployment of the chain codes; secondly, extracting and abstracting static structural features of chain code security vulnerabilities, and compiling corresponding vulnerability detection rules aiming at the structural features of each vulnerability; and finally, applying a group of vulnerability detection rules to carry out feature matching of the vulnerabilities, and if the matching is successful, considering that the corresponding security vulnerabilities exist in the chain codes, wherein the method specifically comprises the following steps:
step 1, obtaining static structure information of a chain code according to an abstract syntax tree of the chain code;
the abstract syntax tree of the chain code is obtained through the lexical analysis and syntax analysis functions in the Go compiler: using a chain code file as input, generating a recognizable Token sequence through lexical analysis, and then rewriting the generated Token sequence by using a bottom-up analysis method through syntactic analysis to construct AST of a chain code; the abstract syntax tree is constructed by subtrees, gradually combined upwards and finally assembled into a complete abstract syntax tree; file nodes are used as root nodes in an abstract syntax tree of chain codes, other nodes describe the syntax structures of different levels of a file from top to bottom, and each node has detailed structure statement and definition thereof and represents the position of the node in the chain codes and the relation with other nodes;
step 2, compiling corresponding vulnerability detection rules according to the static structure characteristics of the chain code vulnerability;
when vulnerability detection is performed on the chain code, a group of detection rules are specified according to the needs of a user, each detection rule corresponds to a type of vulnerability, and the addition of new vulnerability rules and the deletion of outdated vulnerability rules are supported; identifying different types of vulnerabilities by running different detection rules in the detection process;
the written vulnerability detection rules are specifically as follows:
global variable/field declaration: firstly, local variables declared in a function are collected, and non-local variables in a program are taken as global variables;
iteration of the mapping range: ranging stmt is in AST, which indicates that iterative operation exists in a program, and whether an operation object is mapping is detected;
and (3) concurrent program generation: go project is used if AST is present in AST;
random number generation: checking whether a packet imported by a program has math/rand;
system time stamping: checking whether time exists in a package imported by a program;
web services: checking whether net exists in a package imported by a program;
and (3) system command execution: checking whether the package imported by the program has os/exec;
external file access: checking whether the package imported by the program has io/ioutil;
external library calling: continuously enriching external libraries that may introduce uncertainty;
and (3) phantom reading: checking whether a range query function exists in the function call, and if so, checking whether a function call of a write operation exists in a subtree of the function call;
reading after writing: checking whether a write operation exists in the function call, and if so, checking whether a read operation exists in a subtree of the function call and whether the objects of the write operation and the read operation are the same;
step 3, applying a vulnerability detection rule to carry out vulnerability feature matching; the specific detection sequence is as follows:
(1) checking the imported library: firstly, checking a program package imported in a chain code by checking an ImportSpec node of an abstract syntax tree; if no program package related to the security vulnerability exists, skipping detection of the vulnerability;
(2) checking the global variable: identifying global variables used in the chain code by examining the Tok value and the ValueSpec value in the abstract syntax tree; if a global variable is detected in the step, recording the problem and giving the position of the problem in the abstract syntax tree so as to search the position of the vulnerability in the chain code when a detection report is generated subsequently;
(3) detecting vulnerability related to variables: detecting risks related to the variables according to the program packages imported in the chain codes; if a variable that assigns an uncertainty value is used in the ledger operation and control flow statements, the operation is deemed unsafe;
(4) detecting a variable-independent vulnerability: checking whether a calling path of a range query function exists in function calling or not by checking a FuncDecl node and a CallExpr node in an abstract syntax tree to detect whether a 'phantom reading' vulnerability exists or not; checking whether a go statement related to concurrency exists or not by checking a GoStmt node to detect whether a 'program concurrency' bug exists or not;
and 4, outputting the brief description of the detected vulnerability in the chain code and the position of the vulnerability in the chain code to the user interface according to a predefined output format, and counting the detection result.
Adopt the produced beneficial effect of above-mentioned technical scheme to lie in: the vulnerability detection method aiming at the Go language chain code effectively locates the vulnerability existing in the chain code by executing static analysis on the abstract syntax tree, and has outstanding speed advantage compared with a detection tool of the Go language. The method not only makes up the blank of the current security analysis scheme for the Fabric chain code, but also supports continuous expansion of a new vulnerability detection mechanism.
Drawings
Fig. 1 is a flowchart of a vulnerability detection method for Go language chain codes according to an embodiment of the present invention;
FIG. 2 is a diagram illustrating an abstract syntax tree structure according to the present invention;
fig. 3 is a design class diagram of the vulnerability detection system of Go language chain codes provided by the embodiment of the present invention;
fig. 4 is a working sequence diagram of the vulnerability detection system according to the embodiment of the present invention;
FIG. 5 is a flowchart of phantom read vulnerability detection provided by an embodiment of the present invention;
fig. 6 is a flowchart of iterative vulnerability detection for a mapping range according to an embodiment of the present invention.
Detailed Description
The following detailed description of embodiments of the present invention is provided in connection with the accompanying drawings and examples. The following examples are intended to illustrate the invention but are not intended to limit the scope of the invention.
In the embodiment, a vulnerability detection method for Go language chain codes includes the steps that firstly, in a chain code development stage or before deployment, static structure characteristics of the chain codes are obtained through analyzing an abstract syntax tree of the Go language chain codes; secondly, extracting and abstracting static structural features of chain code security vulnerabilities, and compiling corresponding vulnerability detection rules aiming at the structural features of each vulnerability; finally, a group of vulnerability detection rules are applied to carry out feature matching of vulnerabilities, if matching is successful, corresponding security vulnerabilities existing in the chain codes are considered, and as shown in fig. 1, the method specifically comprises the following steps:
step 1, obtaining static structure information of a chain code according to an abstract syntax tree of the chain code;
the abstract syntax tree of the chain code is obtained through the lexical analysis and syntax analysis functions in the Go compiler: using a chain code file as input, generating a recognizable Token sequence through lexical analysis, and then rewriting the generated Token sequence by using a bottom-up analysis method through syntactic analysis to construct AST of a chain code; the abstract syntax tree is constructed by subtrees, gradually combined upwards and finally assembled into a complete abstract syntax tree; the abstract syntax tree of the chain code is shown in fig. 2, and as last.file node is used as a root node, other nodes describe the syntax structure of different levels of the file from top to bottom, and each node has its detailed structure declaration and definition, which represents its position in the chain code and the relationship with other nodes, for example, as.ident represents the name of the identifier and the position in the chain code file; GenDecl represents all import declarations except functions, namely import, const, var and type related information; funcdecl denotes a function declaration; the ast.imports spec node represents the import of a single program package, and the ast.basiclit node represents the text content corresponding to one basic type.
Step 2, compiling corresponding vulnerability detection rules according to the static structure characteristics of the chain code vulnerability;
when vulnerability detection is performed on the chain code, a group of detection rules are specified according to the needs of a user, each detection rule corresponds to a type of vulnerability, and the addition of new vulnerability rules and the deletion of outdated vulnerability rules are supported; different detection rules are operated in the detection process, different types of bugs are identified, and the design also enables the method to have good expansibility.
The written detection rules and corresponding vulnerability specifications are shown in table 1:
TABLE 1 vulnerability detection rules and corresponding vulnerability specifications
Step 3, applying a vulnerability detection rule to carry out vulnerability feature matching; the specific detection sequence is as follows:
(1) checking the imported library: firstly, checking a program package imported in a chain code by checking an ImportSpec node of an abstract syntax tree; if there are no packages associated with security vulnerabilities (e.g., "random number generation," "system timestamp function," "Web service," and "system command execution"), then detection of such vulnerabilities is skipped;
(2) checking the global variable: by examining the Tok value and the ValueSpec value in the abstract syntax tree, the global variable used in the chain code can be identified; if a global variable is detected in the step, recording the problem and giving the position of the problem in the abstract syntax tree so as to search the position of the vulnerability in the chain code when a detection report is generated subsequently;
(3) detecting vulnerability related to variables: detecting risk (e.g., random numbers and timestamps) associated with the variables from the packages imported in the chain code; if a variable that assigns an uncertainty value is used in both the ledger operation (e.g., PutState) and the control flow statement (e.g., if statement), the operation is deemed unsafe;
(4) detecting a variable-independent vulnerability: part of the risk is independent of variables, such as goroutine, phantom reading, etc.; checking whether a call path of a range query function such as GetQueryResult (), GetHistoryForKey () and GetPrivatedDataQueryResult () exists in the function call by checking a FuncDecl node and a CallExpr node in an abstract syntax tree to detect whether a 'ghost read' vulnerability exists; checking whether a go statement related to concurrency exists or not by checking a GoStmt node to detect whether a 'program concurrency' bug exists or not;
and 4, outputting the brief description of the detected vulnerability in the chain code and the position of the vulnerability in the chain code to the user interface according to a predefined output format, and counting the detection result.
A class diagram is a modeling diagram for describing various concepts in a system by identifying different entities (people, things, data) in the system and delineating relationships between them. It can give a static view structure of the system. In this embodiment, a design class diagram of a vulnerability detection system written by using the vulnerability detection method for Go language chain codes of the present invention is given, as shown in fig. 3. The file class acquires and preprocesses the chain code content, and provides the chain code content for the detection rule to execute analysis; similarly, the failure class defines an error information format, which is convenient for the format to output the detection result in a specific form.
In order to unify the development of detection rules and output modes and subsequent expansion, an interface of a rule and a format is designed. rule1, rule2, rule3 and format 1, format 2 are specific implementations of rule interfaces and format interfaces, respectively. The rule interface includes two abstract functions: the rule name () function returns the name of the detection rule, and the application () function executes corresponding vulnerability analysis according to the transmitted parameters and the preprocessed chain code content transmitted by the dependent file class; abstract functions in the format interface include: and name () returns an output format name, and format () dependently detects the generated error information in the failure format and outputs the error information to a user interface or generates a log file according to a specific form.
The config class acquires the detection rule and the output format required by the analysis through user input, and is associated with the rule class and the format class. The line class is associated with the file class to acquire chain code content to be detected, and the config class is associated to complete the detection and output process.
In order to further describe how the modules in fig. 3 dynamically interact in time sequence, in this embodiment, a system sequence diagram of a vulnerability detection system written by using the vulnerability detection method for Go language chain codes of the present invention is given, as shown in fig. 4.
After the user inputs an instruction from the command line, the config class and the file class are activated and command parameters are acquired. The config class reads configuration information provided by a user, respectively activates a format and a rule to acquire an output format and a detection rule list specified by the user, and sends the output format and the detection rule list to the line class; similarly, the file class acquires the chain code to be detected according to the command parameter and sends the preprocessed chain code information to the line class. The linter class calls a corresponding rule interface according to the detection rule list to detect the chain code and record the returned error information. And after the detection rule in the list is executed, sending the error information to a format interface appointed by a user, and outputting the error information to a command line interface by the format interface according to format requirements to finish the detection work.
In this embodiment, as shown in fig. 5, the detection process of the vulnerability read by using the vulnerability detection method of the present invention specifically includes:
step S1: traversing AST (abstract syntax tree) of the chain code, if no nodes which are not traversed remain, exiting the traversal, and ending the detection process; otherwise, continuing to execute step S2;
step S2: judging whether the current node type is ast.FuncDecl (node for recording function information), if not, jumping to the step 1, and if so, continuing to execute the step S3;
step S3: traversing the subtree of the node, if no nodes which are not traversed remain, exiting the traversal, and jumping to the step S1; otherwise, continuing to execute step S4;
step S4: determining whether the current node type is ast.callexpr (a node recording function call information), if not, jumping to step S3, and if so, continuing to execute step S5;
step S5: traversing the function call list in the node, if the list is traversed to the end, exiting the traversal, and jumping to the step S3; otherwise, continuing to execute step S6;
step S6: judging whether a GetHistoryForKey or a GetQueryResult function exists in the function call list, if so, recording the called position Local and the parameter getKey, and jumping to the step S5;
step S7: judging whether a PutState function exists in the function call list, if so, recording the called position Local2 and the parameter writeKey and continuing to execute the step S8, otherwise, jumping to the step S5;
step S8: judging whether the writeKey is not equal to all the getKey, if so, jumping to the step S5; otherwise, judging whether the location Local of the writeKey is larger than the location Local of the getKey which is equal to the writeKey, if so, continuing to execute the step S9, otherwise, jumping to the step S5;
step S9: whether a PutState function exists in the function call list or not, if so, recording the position of the call and a parameter writeKey and continuing to execute the step S10, otherwise, jumping to the step S5;
step S10: and recording the values of the getKey and the weiteKey and the corresponding Local, prompting the user to find a 'phantom reading' bug, and exiting the loop to finish execution.
In this embodiment, as shown in fig. 6, the detection process of the vulnerability detection method according to the present invention for "mapping range iteration" vulnerability specifically includes:
step C1: traversing AST (abstract syntax tree) of the chain code, if no nodes which are not traversed remain, exiting the traversal, and ending the detection process; otherwise, continuing to execute the step C2;
step C2: determining whether the current node type is ast.rangestmt (if the node exists, it indicates that a range statement exists), if not, jumping to step C1, and if so, continuing to execute step C3;
step C3: traversing the subtree of the node to obtain the parameters of the range statement, if no nodes which are not traversed remain, exiting from the traversal, and jumping to the step C1; otherwise, continuing to execute the step C4;
step C4: judging whether the parameter of the range statement is a map structure, if so, continuing to execute the step C5, otherwise, jumping to the step C3;
step C5: and recording the position and the parameters of the range statement, prompting a user to find a mapping range iteration bug, and exiting the loop to finish execution.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions and scope of the present invention as defined in the appended claims.
Claims (5)
1. A vulnerability detection method aiming at Go language chain codes is characterized by comprising the following steps:
in a chain code development stage or before deployment, obtaining static structure characteristics of a chain code by analyzing an abstract syntax tree of the Go language chain code;
extracting and abstracting static structure characteristics of chain code security vulnerabilities;
writing a corresponding vulnerability detection rule aiming at the structural characteristics of each vulnerability;
and applying a group of vulnerability detection rules to carry out vulnerability feature matching, and if matching is successful, considering that the corresponding security vulnerability exists in the chain code.
2. The method for vulnerability detection to Go language chain codes according to claim 1, wherein: the method specifically comprises the following steps:
step 1, obtaining static structure information of a chain code according to an abstract syntax tree of the chain code;
step 2, compiling corresponding vulnerability detection rules according to the static structure characteristics of the chain code vulnerability;
when vulnerability detection is performed on the chain code, a group of detection rules are specified according to the needs of a user, each detection rule corresponds to a type of vulnerability, and the addition of new vulnerability rules and the deletion of outdated vulnerability rules are supported; identifying different types of vulnerabilities by running different detection rules in the detection process;
step 3, applying a vulnerability detection rule to carry out vulnerability feature matching;
and 4, outputting the brief description of the detected vulnerability in the chain code and the position of the vulnerability in the chain code to the user interface according to a predefined output format, and counting the detection result.
3. The method for vulnerability detection to Go language chain codes according to claim 2, wherein: the abstract syntax tree of the chain code is obtained through the lexical analysis and syntax analysis functions in the Go compiler: using a chain code file as input, generating a recognizable Token sequence through lexical analysis, and then rewriting the generated Token sequence by using a bottom-up analysis method through syntactic analysis to construct AST of a chain code; the abstract syntax tree is constructed by subtrees, gradually combined upwards and finally assembled into a complete abstract syntax tree; file node is used as root node, other nodes describe the syntactic structure of different levels of the file from top to bottom, and each node has its detailed structural statement and definition, which represents its position in the chain code and its relationship with other nodes.
4. The method for vulnerability detection to Go language chain codes according to claim 2, wherein: the written vulnerability detection rules are specifically as follows:
global variable/field declaration: firstly, local variables declared in a function are collected, and non-local variables in a program are taken as global variables;
iteration of the mapping range: ranging stmt is in AST, which indicates that iterative operation exists in a program, and whether an operation object is mapping is detected;
and (3) concurrent program generation: go project is used if AST is present in AST;
random number generation: checking whether a packet imported by a program has math/rand;
system time stamping: checking whether time exists in a package imported by a program;
web services: checking whether net exists in a package imported by a program;
and (3) system command execution: checking whether the package imported by the program has os/exec;
external file access: checking whether the package imported by the program has io/ioutil;
external library calling: continuously enriching external libraries that may introduce uncertainty;
and (3) phantom reading: checking whether a range query function exists in the function call, and if so, checking whether a function call of a write operation exists in a subtree of the function call;
reading after writing: and checking whether a write operation exists in the function call, and if so, checking whether a read operation exists in a subtree of the function call and whether the objects of the write operation and the read operation are the same.
5. The method of claim 4, wherein the vulnerability detection method for Go language chain codes comprises: the specific detection sequence of the vulnerability characteristic matching by applying the vulnerability detection rule in the step 3 is as follows:
(1) checking the imported library: firstly, checking a program package imported in a chain code by checking an ImportSpec node of an abstract syntax tree; if no program package related to the security vulnerability exists, skipping detection of the vulnerability;
(2) checking the global variable: identifying global variables used in the chain code by examining the Tok value and the ValueSpec value in the abstract syntax tree; if a global variable is detected in the step, recording the problem and giving the position of the problem in the abstract syntax tree so as to search the position of the vulnerability in the chain code when a detection report is generated subsequently;
(3) detecting vulnerability related to variables: detecting risks related to the variables according to the program packages imported in the chain codes; if a variable that assigns an uncertainty value is used in the ledger operation and control flow statements, the operation is deemed unsafe;
(4) detecting a variable-independent vulnerability: checking whether a calling path of a range query function exists in function calling or not by checking a FuncDecl node and a CallExpr node in an abstract syntax tree to detect whether a 'phantom reading' vulnerability exists or not; and checking the GoStmt node to see whether a go statement related to concurrency exists or not to detect whether a program concurrency bug exists.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111654617.1A CN114329492A (en) | 2021-12-30 | 2021-12-30 | Vulnerability detection method for Go language chain code |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111654617.1A CN114329492A (en) | 2021-12-30 | 2021-12-30 | Vulnerability detection method for Go language chain code |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114329492A true CN114329492A (en) | 2022-04-12 |
Family
ID=81019963
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111654617.1A Pending CN114329492A (en) | 2021-12-30 | 2021-12-30 | Vulnerability detection method for Go language chain code |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114329492A (en) |
-
2021
- 2021-12-30 CN CN202111654617.1A patent/CN114329492A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112100054B (en) | Data management and control oriented program static analysis method and system | |
| US10698682B1 (en) | Computerized software development environment with a software database containing atomic expressions | |
| Gargantini et al. | A metamodel-based language and a simulation engine for abstract state machines. | |
| US8122440B1 (en) | Method and apparatus for enumerating external program code dependencies | |
| US11294665B1 (en) | Computerized software version control with a software database and a human database | |
| US11262988B2 (en) | Method and system for using subroutine graphs for formal language processing | |
| CN112256271A (en) | Block chain intelligent contract security detection system based on static analysis | |
| Dias et al. | Verifying concurrent programs using contracts | |
| Negrini | A generic framework for multilanguage analysis | |
| Cogumbreiro et al. | Checking data-race freedom of gpu kernels, compositionally | |
| Tuong et al. | Deeply integrating C11 code support into Isabelle/PIDE | |
| Lohmann | A feature-complete Petri net semantics for WS-BPEL 2.0 and its compiler BPEL2oWFN | |
| Cogumbreiro et al. | Memory access protocols: certified data-race freedom for GPU kernels | |
| Khalil et al. | Optimizing the symbolic execution of evolving rhapsody statecharts | |
| Briand et al. | Using aspect-oriented programming to instrument ocl contracts in java | |
| CN114329492A (en) | Vulnerability detection method for Go language chain code | |
| Sousa et al. | Preventing atomicity violations with contracts | |
| Agape et al. | P4fuzz: A compiler fuzzer for securing p4 programmable dataplanes | |
| Girka et al. | A mechanically checked generation of correlating programs directed by structured syntactic differences | |
| CN109271237B (en) | Simulation control method and device | |
| Drago | Quality driven model transformations for feedback provisioning | |
| Mennie et al. | Giving meaning to macros | |
| Facchinetti et al. | Higher-order demand-driven program analysis | |
| Ringdal | Automated Refactoring of Rust Programs | |
| Tuong et al. | Isabelle/C |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |