Implement InvalidMemory3, Rule 18-8 amendment. #750
Conversation
c/misra/test/rules/RULE-18-8/test.c
Outdated
|
|
||
| // 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.
There was a problem hiding this comment.
I'm happy to do it that way, and I think the first point is a good reason why we would want to do it this way. That said, in my conversations with Robert, our conclusion was that 18-8 is intended to reject allocating VLAs. It's the allocation of a VLA that makes them so dangerous to use. In my head, a VLA is an object in memory, while a VLA type is the static type of that object, and the rule now states that it's VLAs which are banned, not VLA types.
Of course, an unused VLA typedef should be deleted. And most uses of a VLA typedef would be invalid. But in theory, not all. A VLA typedef could be used in a sizeof(), or it could be used in a context where it is adjusted to a pointer.
I don't think these cases are likely to come up, I did want to document them correctly in the tests.
Perhaps I should add this explanation in a comment?
There was a problem hiding this comment.
Re-reading the rule, I think your interpretation as it intending to identify allocations is correct. The rule starts by saying:
Variable-length arrays are specified when the size of an array declared in a block or function prototype is not an integer constant expression.
Which would exclude an unused typedef, or a typedef that is not used to declare an array in a block or function prototype. This was a change from the previous interpretation for Rule 18.8 in MISRA C 2012.
I think there's two options for how we handle this:
- We continue to flag the typedef, but only report it if we find it used as the type in a variable declaration in a "valid" location - e.g. where there exists a
Variablewhose type is the typedef (or derived from the typedef?). We could add theVariables as placeholders in this case. - We re-jig the query to report
Variables, where theVariableis thegetVariable()of theVlaDeclStmtor where the variable type is a use of a theTypeDefassociated with aVlaDeclStmt.
If you've used a typedef I think it's likely you're intending to use the type in multiple places, so I would say that's an argument to continue to flag the typedef. However, it may not be that common in practice, so it's possibly a premature optimization in reporting.
There was a problem hiding this comment.
Resolved via 2!
| 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.
There was a problem hiding this comment.
We can exclude that case. In general, it'd be easy to exclude all cases where the declaration entry isGeneratedByMacro.
However, it's worth noting that the false positives are incomplete array types. Variables can't be declared with incomplete array types. So the cases where this would flag multiple things because they all match would be a pretty unusual case where, for instance, multiple declared variables have function types with incomplete array types as parameters.
There was a problem hiding this comment.
Could we detect when this issue had occurred by determining if the number of VlaDeclStmt and the number candidates that occur at the same location match? Then avoid reporting in the case where it doesn't?
There was a problem hiding this comment.
Very reasonable, will do!
c/misra/src/rules/RULE-18-9/ArrayToPointerConversionOfTemporaryObject.ql
Outdated
Show resolved
Hide resolved
c/misra/src/rules/RULE-18-9/ArrayToPointerConversionOfTemporaryObject.ql
Outdated
Show resolved
Hide resolved
c/misra/src/rules/RULE-18-9/ArrayToPointerConversionOfTemporaryObject.ql
Show resolved
Hide resolved
| /** | ||
| * A declaration involving a variably-modified type. | ||
| */ | ||
| class VmtDeclarationEntry extends DeclarationEntry { |
There was a problem hiding this comment.
I think we're only interested in variable declarations, right?
| class VmtDeclarationEntry extends DeclarationEntry { | |
| class VmtDeclarationEntry extends VariableDeclarationEntry { |
There was a problem hiding this comment.
This actually causes the query to exclude the typedef results, since those also use DeclarationEntrys
c/misra/src/rules/RULE-18-9/ArrayToPointerConversionOfTemporaryObject.ql
Outdated
Show resolved
Hide resolved
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.