rule generator: insert default child statement when specifying basic block subscope
See original GitHub issueThe rule generator recognizes the following as a valid rule (Rule compiled and matched):
features:
- and:
- offset: 0x10
- offset: 0x14
But it complains that when adding a basic block (failed to match rule):
features:
- and:
- offset: 0x10
- basic block:
- offset: 0x14
Adding an extra element to the basic block, it claims that it failed to compile the rule (invalid rule: subscope must have exactly one child statement):
features:
- and:
- basic block:
- offset: 0x14
- offset: 0x10
It looks like something is wrong with basic blocks as both should be valid rules and match.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (1 by maintainers)
Top Results From Across the Web
Java - Coding Rules
This rule raises an issue when classes with non- private constructors (including the default constructor) use field injection. Noncompliant Code Example. class ...
Read more >@babel/plugin-transform-block-scoped-functions | Yarn - Package ...
Fast, reliable, and secure dependency management.
Read more >Simple Presentation Web App Generator
To add more slides to a SPWAG presentation, simply define another slide. ... The end keyword ends a block of code, started by...
Read more >Computer Language & Compilers
is the description of method (rules) of how to construct a certain ... default: raise ERROR; ... A Basic Block is a consecutive...
Read more >Visitor-based Attribute Grammars with ... - ScienceDirect.com
Abstract. The visitor design pattern is often applied to program traversal algorithms over Abstract Syntax Trees. (ASTs). It defines a visitor, ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes, I think checking the type makes sense.
Hm I’m guessing the second rule is “valid” in the sense that it contains exactly one child element, but capa won’t be able to find a match for it because the type of the child statement is not as expected. If you nested
- offset: 0x14
underneath anand
oror
statement then the rule is valid and capa should be able to find a match for it.We should modify the check to verify that a
subscope
has exactly one child element AND it’s of the expected type. Unless this additional check is performed later?Thoughts @mr-tz?