Implement InvalidMemory3, Rule 18-8 amendment. #750
Conversation
|
|
||
| // A typedef is not a VLA. However, `VlaDeclStmt`s match the typedef. | ||
| typedef int vlaTypedef[n]; // COMPLIANT[FALSE_POSITIVE] | ||
| vlaTypedef t1; // NON_COMPLIANT[FALSE_NEGATIVE] |
There was a problem hiding this comment.
I think we should remove the false positive and false negative markers here, and accept the existing results as correct.
I justify this in two ways:
- It's more developer friendly to highlight the typedef that introduces the VLA, rather than the actual declaration. It's where they would likely need to fix the problem, and it reduces the number of results that need to be managed vs. every use of the typedef.
- I think that's consistent with how MISRA intended to report the results. This forum post https://forum.misra.org.uk/archive/index.php?thread-1384.html, while not being 100% clear, I think is indicative that typedefs themselves should be considered a use of variable-length arrays.
| arrayType = v.getVariable().getType() | ||
| or | ||
| arrayType = v.getType().getUnspecifiedType() | ||
| ) and |
There was a problem hiding this comment.
Can you add a comment to the two cases above, noting that the getVariable() holds if this is a direct declaration of a variable, and the .getType() case holds is this is a typedef (but not vice versa). I wasn't sure when I first read this why we had both cases.
| select v, "Variable length array declared." | ||
| size = v.getVlaDimensionStmt(0).getDimensionExpr() and | ||
| ( | ||
| arrayType = v.getVariable().getType() |
There was a problem hiding this comment.
Do we need to strip top-level specifiers here as well?
| ( | ||
| arrayType = v.getVariable().getType() | ||
| or | ||
| arrayType = v.getType().getUnspecifiedType() |
There was a problem hiding this comment.
Rather than getUnspecifiedType(), I think it would be better to use stripTopLevelSpecifiers. getUnspecifiedType resolves typedefs, which can be confusing if the base type of the array is a complex type in itself.
| or | ||
| innerType = this.(TypedefType).getBaseType() | ||
| or | ||
| innerType = this.(SpecifiedType).getBaseType() |
There was a problem hiding this comment.
Can we simplify this disjunctive clause by using DerivedType.getBaseType()?
| s.getADeclaration() = entry.getDeclaration() and | ||
| before = s.getLocation() and | ||
| after = before and | ||
| before.subsumes(inner) |
There was a problem hiding this comment.
I think we should consider what happens if the declaration is in a macro. Specifically, what happens if a macro has multiple array declarations, only one of which is a VM. I suspect we'll end up flagging all of them, as they will all have the same location.
Note: that is not a problem for the parameter case, because we require a strict before/after location.
| getUnconverted().getUnspecifiedType() instanceof StructOrUnionTypeWithArrayField and | ||
| not isCLValue(this) | ||
| or | ||
| this.(ArrayExpr).getArrayBase() instanceof TemporaryLifetimeArrayAccess |
There was a problem hiding this comment.
Should this case also use getUnconverted().getUnspecifiedType()?
| or | ||
| result = expr.(BinaryOperation).getRightOperand() | ||
| or | ||
| result = expr.(UnaryOperation).getOperand() |
There was a problem hiding this comment.
The three above can be replaced with Operation.getAnOperand()
| * A pointer-to-array conversion does not need to be flagged if the result of | ||
| * that conversion is not used or stored. | ||
| */ | ||
| Expr usedValuesOf(Expr expr) { |
There was a problem hiding this comment.
The parameter is unused. I'd suggest using the same model as isStored(..), and instead do:
predicate isUsed(Expr e) {
I would also integrate the isStored predicate here.
| predicate isStored(Expr e) { | ||
| e = any(VariableDeclarationEntry d).getDeclaration().getInitializer().getExpr() | ||
| or | ||
| e = any(ClassAggregateLiteral l).getAFieldExpr(_) |
There was a problem hiding this comment.
Integrate this predicate into the usedValuesOf predicate.
Description
Implements package InvalidMemory3, which detects pointer-to-array conversions and modification of array values with temporary lifetimes, (
RULE-18-9) and bans pointers to variably modified types (RULE-18-10).RULE-18-10is marked as "split" fromRULE-18-8in the amendments file, so updateRULE-18-8to only detect allocating VLA declarations. In the process, remove potential false positives around incomplete array parameter types, eg,f(int arr[]). To protect against the same false positives from occurring inRULE-18-10, use locations that correspond withVlaDimensionStmtinstances.If it is better to split this PR up, I'm happy to do so!
Change request type
.ql,.qll,.qlsor unit tests)Rules with added or modified queries
RULE-18-9RULE-18-10RULE-18-8Release change checklist
A change note (development_handbook.md#change-notes) is required for any pull request which modifies:
If you are only adding new rule queries, a change note is not required.
Author: Is a change note required?
🚨🚨🚨
Reviewer: Confirm that format of shared queries (not the .qll file, the
.ql file that imports it) is valid by running them within VS Code.
Reviewer: Confirm that either a change note is not required or the change note is required and has been added.
Query development review checklist
For PRs that add new queries or modify existing queries, the following checklist should be completed by both the author and reviewer:
Author
As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
Reviewer
As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.