Implement InvalidMemory3, Rule 18-8 amendment.

[MichaelRFairhurst]

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-10 is marked as "split" from RULE-18-8 in the amendments file, so update RULE-18-8 to 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 in RULE-18-10, use locations that correspond with VlaDimensionStmt instances.

If it is better to split this PR up, I'm happy to do so!

Change request type

• Release or process automation (GitHub workflows, internal scripts)
• Internal documentation
• External documentation
• Query files (.ql, .qll, .qls or unit tests)
• External scripts (analysis report or other code shipped as part of a release)

Rules with added or modified queries

• No rules added
• Queries have been added for the following rules:
  • RULE-18-9
  • RULE-18-10
• Queries have been modified for the following rules:
  • RULE-18-8

Release change checklist

A change note (development_handbook.md#change-notes) is required for any pull request which modifies:

• The structure or layout of the release artifacts.
• The evaluation performance (memory, execution time) of an existing query.
• The results of an existing query in any circumstance.

If you are only adding new rule queries, a change note is not required.

Author: Is a change note required?

• Yes
• No

🚨🚨🚨
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.

• Confirmed

Reviewer: Confirm that either a change note is not required or the change note is required and has been added.

• Confirmed

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

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  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.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

Reviewer

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  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.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

[lcartey]

Thanks! Some suggestions and comments to follow up on individual files.

[lcartey]

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:

1. 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.
2. 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.

[MichaelRFairhurst]

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?

[lcartey]

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.

[MichaelRFairhurst]

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.