Implement C Declarations7 package

[knewbury01]

Description

Decl7 package

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-8-12
  • RULE-18-8
  • DCL36-C (wont implement decision - pls verify if agreed - notes on justification below
  • DCL39-C (import DCL55-CPP)
• Queries have been modified for the following rules:
  • rule number here

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!)

[knewbury01]

Notes on justification for omit DCL36-C decision

compiler checked by clang (and according to wiki, gcc) but not MVSC

verified with:
testcase non compliant example from the wiki

as well as this testcase built upon the table depicted in the wiki (except if the "no linkage" header actually said "no specifier" which I think is what is it is meant to say - to be confirmed)

////TABLE - specifiers

static int i1; //internal linkage
static int i1; //COMPLIANT - internal linkage


int i2; //no linkage
static int i2; //NON_COMPLIANT - undefined - compiler detected

extern int i3; //external linkage
static int i3; ///NON_COMPLIANT - undefined - compiler detected


//-----
static int i11; //internal linkage
int i11; //NON_COMPLIANT - undefined - compiler detected

int i22; //no specifier
int i22; //COMPLIANT - no specifier


extern int i33; //external linkage
int i33; //NON_COMPLIANT - undefined according to table - but not compiler detected - so... COMPLIANT?
//see NOTE2 below ^^

//-----
static int i111; //internal linkage
extern int i111; //COMPLIANT - internal linkage

int i222; //no specifier
extern int i222; //COMPLIANT - external linkage

extern int i333; //external linkage
extern int i333; //COMPLIANT - external linkage

NOTE2: additionally , the wiki NON_COMPLIANT example is verbatim from the standard 6.9.2 Example 1, where I believe this case is equivalent to:

int i4; // tentative definition, external linkage
int i4; // valid tentative definition, refers to previous

[jsinglet]

Looking good @knewbury01! Some minor comments and a question about how you want to handle edge cases not being handled.

[jsinglet]

LGTM!