From 5bcf11dae3b7a56127f91a6801a3f94ef5fd1bc9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Palmer?= Date: Thu, 29 Feb 2024 16:30:38 +0100 Subject: [PATCH] Cppcheck: add misra checks --- .github/workflows/cppcheck.yml | 2 +- misra.json | 7 + misra.md | 728 +++++++++++++++++++++++++++++++++ 3 files changed, 736 insertions(+), 1 deletion(-) create mode 100644 misra.json create mode 100644 misra.md diff --git a/.github/workflows/cppcheck.yml b/.github/workflows/cppcheck.yml index 39a895a0..ab91e79a 100644 --- a/.github/workflows/cppcheck.yml +++ b/.github/workflows/cppcheck.yml @@ -16,4 +16,4 @@ jobs: ref: ${{ github.ref }} - name: Check - run: cppcheck --quiet --error-exitcode=1 src/ + run: cppcheck --addon=misra.json --quiet --error-exitcode=1 src/ diff --git a/misra.json b/misra.json new file mode 100644 index 00000000..6f5e0066 --- /dev/null +++ b/misra.json @@ -0,0 +1,7 @@ +{ + "script": "misra.py", + "args": [ + "--rule-texts=misra.md", + "--suppress-rules 2.7,3.1,7.4,8.14,8.2,8.4,8.9,9.2,10.1,10.3,10.4,10.5,10.6,11.1,11.3,11.5,11.8,12.3,13.3,13.4,14.2,14.4,15.5,16.2,16.3,16.4,16.5,16.6,17.7,17.8,18.4,18.8,19.2,20.5,20.7,21.15,21.16" + ] +} diff --git a/misra.md b/misra.md new file mode 100644 index 00000000..a3041a5c --- /dev/null +++ b/misra.md @@ -0,0 +1,728 @@ +# Appendix A Summary of guidelines + + +## The implementation + + +Dir 1.1 Required +Any implementation-defined behaviour on which the output of the +program depends shall be documented and understood + + +## Compilation and build + + +Dir 2.1 Required +All source files shall compile without any compilation errors + + +## Requirements traceability + + +Dir 3.1 Required +All code shall be traceable to documented requirements + + +## Code design + + +Dir 4.1 Required +Run-time failures shall be minimized + +Dir 4.2 Advisory +All usage of assembly language should be documented + +Dir 4.3 Required +Assembly language shall be encapsulated and isolated + +Dir 4.4 Advisory +Sections of code should not be “commented out” + +Dir 4.5 Advisory +Identifiers in the same name space with overlapping visibility should be +typographically unambiguous + +Dir 4.6 Advisory +typedefs that indicate size and signedness should be used in place of the +basic numerical types + +Dir 4.7 Required +If a function returns error information, then that error information shall +be tested + +Dir 4.8 Advisory +If a pointer to a structure or union is never dereferenced within a +translation unit, then the implementation of the object should be +hidden + +Dir 4.9 Advisory +A function should be used in preference to a function-like macro where +they are interchangeable + +Dir 4.10 Required +Precautions shall be taken in order to prevent the contents of a header +file being included more than once + +Dir 4.11 Required +The validity of values passed to library functions shall be checked + +Dir 4.12 Required +Dynamic memory allocation shall not be used + +Dir 4.13 Advisory +Functions which are designed to provide operations on a resource +should be called in an appropriate sequence + + +## A standard C environment + + +Rule 1.1 Required +The program shall contain no violations of the standard C syntax and +constraints, and shall not exceed the implementation’s translation limits + +Rule 1.2 Advisory +Language extensions should not be used + +Rule 1.3 Required +There shall be no occurrence of undefined or critical unspecified +behaviour + +Rule 1.4 Required +Emergent language features shall not be used + + +## Unused code + + +Rule 2.1 Required +A project shall not contain unreachable code + +Rule 2.2 Required +There shall be no dead code + +Rule 2.3 Advisory +A project should not contain unused type declarations + +Rule 2.4 Advisory +A project should not contain unused tag declarations + +Rule 2.5 Advisory +A project should not contain unused macro declarations + +Rule 2.6 Advisory +A function should not contain unused label declarations + +Rule 2.7 Advisory +There should be no unused parameters in functions + + +## Comments + + +Rule 3.1 Required +The character sequences /* and // shall not be used within a comment + +Rule 3.2 Required +Line-splicing shall not be used in // comments + + +## Character sets and lexical conventions + + +Rule 4.1 Required +Octal and hexadecimal escape sequences shall be terminated + +Rule 4.2 Advisory +Trigraphs should not be used + + +## Identifiers + + +Rule 5.1 Required +External identifiers shall be distinct + +Rule 5.2 Required +Identifiers declared in the same scope and name space shall be distinct + +Rule 5.3 Required +An identifier declared in an inner scope shall not hide an identifier +declared in an outer scope + +Rule 5.4 Required +Macro identifiers shall be distinct + +Rule 5.5 Required +Identifiers shall be distinct from macro names + +Rule 5.6 Required +A typedef name shall be a unique identifier + +Rule 5.7 Required +A tag name shall be a unique identifier + +Rule 5.8 Required +Identifiers that define objects or functions with external linkage shall be +unique + +Rule 5.9 Advisory +Identifiers that define objects or functions with internal linkage should +be unique + + +## Types + + +Rule 6.1 Required +Bit-fields shall only be declared with an appropriate type + +Rule 6.2 Required +Single-bit named bit fields shall not be of a signed type + + +## Literals and constants + + +Rule 7.1 Required +Octal constants shall not be used + +Rule 7.2 Required +A “u” or “U” suffix shall be applied to all integer constants that are +represented in an unsigned type + +Rule 7.3 Required +The lowercase character “l” shall not be used in a literal suffix + +Rule 7.4 Required +A string literal shall not be assigned to an object unless the object’s type +is “pointer to const-qualified char” + + +## Declarations and definitions + + +Rule 8.1 Required +Types shall be explicitly specified + +Rule 8.2 Required +Function types shall be in prototype form with named parameters + +Rule 8.3 Required +All declarations of an object or function shall use the same names and +type qualifiers + +Rule 8.4 Required +A compatible declaration shall be visible when an object or function +with external linkage is defined + +Rule 8.5 Required +An external object or function shall be declared once in one and only +one file + +Rule 8.6 Required +An identifier with external linkage shall have exactly one external +definition + +Rule 8.7 Advisory +Functions and objects should not be defined with external linkage if +they are referenced in only one translation unit + +Rule 8.8 Required +The static storage class specifier shall be used in all declarations of +objects and functions that have internal linkage + +Rule 8.9 Advisory +An object should be defined at block scope if its identifier only appears +in a single function + +Rule 8.10 Required +An inline function shall be declared with the static storage class + +Rule 8.11 Advisory +When an array with external linkage is declared, its size should be +explicitly specified + +Rule 8.12 Required +Within an enumerator list, the value of an implicitly-specified +enumeration constant shall be unique + +Rule 8.13 Advisory +A pointer should point to a const-qualified type whenever possible + +Rule 8.14 Required +The restrict type qualifier shall not be used + + +## Initialization + + +Rule 9.1 Mandatory +The value of an object with automatic storage duration shall not be read +before it has been set + +Rule 9.2 Required +The initializer for an aggregate or union shall be enclosed in braces + +Rule 9.3 Required +Arrays shall not be partially initialized + +Rule 9.4 Required +An element of an object shall not be initialized more than once + +Rule 9.5 Required +Where designated initializers are used to initialize an array object the +size of the array shall be specified explicitly + + +## The essential type model + + +Rule 10.1 Required +Operands shall not be of an inappropriate essential type + +Rule 10.2 Required +Expressions of essentially character type shall not be used +inappropriately in addition and subtraction operations + +Rule 10.3 Required +The value of an expression shall not be assigned to an object with a +narrower essential type or of a different essential type category + +Rule 10.4 Required +Both operands of an operator in which the usual arithmetic conversions +are performed shall have the same essential type category + +Rule 10.5 Advisory +The value of an expression should not be cast to an inappropriate +essential type + +Rule 10.6 Required +The value of a composite expression shall not be assigned to an object +with wider essential type + +Rule 10.7 Required +If a composite expression is used as one operand of an operator in which +the usual arithmetic conversions are performed then the other operand +shall not have wider essential type + +Rule 10.8 Required +The value of a composite expression shall not be cast to a different +essential type category or a wider essential type + + +## Pointer type conversions + + +Rule 11.1 Required +Conversions shall not be performed between a pointer to a function +and any other type + +Rule 11.2 Required +Conversions shall not be performed between a pointer to an +incomplete type and any other type + +Rule 11.3 Required +A cast shall not be performed between a pointer to object type and a +pointer to a diff erent object type + +Rule 11.4 Advisory +A conversion should not be performed between a pointer to object and +an integer type + +Rule 11.5 Advisory +A conversion should not be performed from pointer to void into pointer +to object + +Rule 11.6 Required +A cast shall not be performed between pointer to void and an arithmetic +type + +Rule 11.7 Required +A cast shall not be performed between pointer to object and a non- +integer arithmetic type + +Rule 11.8 Required +A cast shall not remove any const or volatile qualification from the type +pointed to by a pointer + +Rule 11.9 Required +The macro NULL shall be the only permitted form of integer null pointer +constant + + +## Expressions + + +Rule 12.1 Advisory +The precedence of operators within expressions should be made +explicit + +Rule 12.2 Required +The right hand operand of a shift operator shall lie in the range zero +to one less than the width in bits of the essential type of the left hand +operand + +Rule 12.3 Advisory +The comma operator should not be used + +Rule 12.4 Advisory +Evaluation of constant expressions should not lead to unsigned integer +wrap-around + + +## Side effects + + +Rule 13.1 Required +Initializer lists shall not contain persistent side effects + +Rule 13.2 Required +The value of an expression and its persistent side effects shall be the +same under all permitted evaluation orders + +Rule 13.3 Advisory +A full expression containing an increment (++) or decrement (--) +operator should have no other potential side effects other than that +caused by the increment or decrement operator + +Rule 13.4 Advisory +The result of an assignment operator should not be used + +Rule 13.5 Required +The right hand operand of a logical && or || operator shall not contain +persistent side effects + +Rule 13.6 Mandatory +The operand of the sizeof operator shall not contain any expression +which has potential side effects + + +## Control statement expressions + + +Rule 14.1 Required +A loop counter shall not have essentially floating type + +Rule 14.2 Required +A for loop shall be well-formed + +Rule 14.3 Required +Controlling expressions shall not be invariant + +Rule 14.4 Required +The controlling expression of an if statement and the controlling +expression of an iteration-statement shall have essentially Boolean type + + +## Control flow + + +Rule 15.1 Advisory +The goto statement should not be used + +Rule 15.2 Required +The goto statement shall jump to a label declared later in the same +function + +Rule 15.3 Required +Any label referenced by a goto statement shall be declared in the same +block, or in any block enclosing the goto statement + +Rule 15.4 Advisory +There should be no more than one break or goto statement used to +terminate any iteration statement + +Rule 15.5 Advisory +A function should have a single point of exit at the end + +Rule 15.6 Required +The body of an iteration-statement or a selection-statement shall be a +compound-statement + +Rule 15.7 Required +All if … else if constructs shall be terminated with an else statement + + +## Switch statements + + +Rule 16.1 Required +All switch statements shall be well-formed + +Rule 16.2 Required +A switch label shall only be used when the most closely-enclosing +compound statement is the body of a switch statement + +Rule 16.3 Required +An unconditional break statement shall terminate every switch-clause + +Rule 16.4 Required +Every switch statement shall have a default label + +Rule 16.5 Required +A default label shall appear as either the first or the last switch label of a +switch statement + +Rule 16.6 Required +Every switch statement shall have at least two switch-clauses + +Rule 16.7 Required +A switch-expression shall not have essentially Boolean type + + +## Functions + + +Rule 17.1 Required +The features of shall not be used + +Rule 17.2 Required +Functions shall not call themselves, either directly or indirectly + +Rule 17.3 Mandatory +A function shall not be declared implicitly + +Rule 17.4 Mandatory +All exit paths from a function with non-void return type shall have an +explicit return statement with an expression + +Rule 17.5 Advisory +The function argument corresponding to a parameter declared to have +an array type shall have an appropriate number of elements + +Rule 17.6 Mandatory +The declaration of an array parameter shall not contain the static +keyword between the [ ] + +Rule 17.7 Required +The value returned by a function having non-void return type shall be +used + +Rule 17.8 Advisory +A function parameter should not be modified + + +## Pointers and arrays + + +Rule 18.1 Required +A pointer resulting from arithmetic on a pointer operand shall address +an element of the same array as that pointer operand + +Rule 18.2 Required +Subtraction between pointers shall only be applied to pointers that +address elements of the same array + +Rule 18.3 Required +The relational operators >, >=, < and <= shall not be applied to objects +of pointer type except where they point into the same object + +Rule 18.4 Advisory +The +, -, += and -= operators should not be applied to an expression of +pointer type + +Rule 18.5 Advisory +Declarations should contain no more than two levels of pointer nesting + +Rule 18.6 Required +The address of an object with automatic storage shall not be copied to +another object that persists after the first object has ceased to exist + +Rule 18.7 Required +Flexible array members shall not be declared + +Rule 18.8 Required +Variable-length array types shall not be used + + +## Overlapping storage + + +Rule 19.1 Mandatory +An object shall not be assigned or copied to an overlapping object + +Rule 19.2 Advisory +The union keyword should not be used + + +## Preprocessing directives + + +Rule 20.1 Advisory +#include directives should only be preceded by preprocessor directives +or comments + +Rule 20.2 Required +The ', " or \ characters and the /* or // character sequences shall not +occur in a header file name + +Rule 20.3 Required +The #include directive shall be followed by either a or +"filename" sequence + +Rule 20.4 Required +A macro shall not be defined with the same name as a keyword + +Rule 20.5 Advisory +#undef should not be used + +Rule 20.6 Required +Tokens that look like a preprocessing directive shall not occur within a +macro argument + +Rule 20.7 Required +Expressions resulting from the expansion of macro parameters shall be +enclosed in parentheses + +Rule 20.8 Required +The controlling expression of a #if or #elif preprocessing directive shall +evaluate to 0 or 1 + +Rule 20.9 Required +All identifiers used in the controlling expression of #if or #elif +preprocessing directives shall be #define’d before evaluation + +Rule 20.10 Advisory +The # and ## preprocessor operators should not be used + +Rule 20.11 Required +A macro parameter immediately following a # operator shall not +immediately be followed by a ## operator + +Rule 20.12 Required +A macro parameter used as an operand to the # or ## operators, which +is itself subject to further macro replacement, shall only be used as an +operand to these operators + +Rule 20.13 Required +A line whose first token is # shall be a valid preprocessing directive + +Rule 20.14 Required +All #else, #elif and #endif preprocessor directives shall reside in the +same file as the #if, #ifdef or #ifndef directive to which they are related + + +## Standard libraries + + +Rule 21.1 Required +#define and #undef shall not be used on a reserved identifier or +reserved macro name + +Rule 21.2 Required +A reserved identifier or macro name shall not be declared + +Rule 21.3 Required +The memory allocation and deallocation functions of shall +not be used + +Rule 21.4 Required +The standard header file shall not be used + +Rule 21.5 Required +The standard header file shall not be used + +Rule 21.6 Required +The Standard Library input/output functions shall not be used + +Rule 21.7 Required +The atof, atoi, atol and atoll functions of shall not be used + +Rule 21.8 Required +The Standard Library termination functions of shall not +be used + +Rule 21.9 Required +The library functions bsearch and qsort of shall not be +used + +Rule 21.10 Required +The Standard Library time and date functions shall not be used + +Rule 21.11 Required +The standard header file shall not be used + +Rule 21.12 Advisory +The exception handling features of should not be used + +Rule 21.13 Mandatory +Any value passed to a function in shall be representable as +an unsigned char or be the value EOF + +Rule 21.14 Required +The Standard Library function memcmp shall not be used to compare null +terminated strings + +Rule 21.15 Required +The pointer arguments to the Standard Library functions memcpy, +memmove and memcmp shall be pointers to qualified or unqualified +versions of compatible types + +Rule 21.16 Required +The pointer arguments to the Standard Library function memcmp shall +point to either a pointer type, an essentially signed type, an +essentially unsigned type, an essentially Boolean type or an +essentially enum type + +Rule 21.17 Mandatory +Use of the string handling functions from shall not result +in accesses beyond the bounds of the objects referenced by their +pointer parameters + +Rule 21.18 Mandatory +The size_t argument passed to any function in shall have an +appropriate value + +Rule 21.19 Mandatory +The pointers returned by the Standard Library functions localeconv, +getenv, setlocale or, strerror shall only be used as if they have +pointer to const-qualified type + +Rule 21.20 Mandatory +The pointer returned by the Standard Library functions asctime, ctime, +gmtime, localtime, localeconv, getenv, setlocale or strerror shall not +be used following a subsequent call to the same function + +Rule 21.21 Required +The Standard Library function system of shall not be +used + + +## Resources + + +Rule 22.1 Required +All resources obtained dynamically by means of Standard Library +functions shall be explicitly released + +Rule 22.2 Mandatory +A block of memory shall only be freed if it was allocated by means of a +Standard Library function + +Rule 22.3 Required +The same file shall not be open for read and write access at the same +time on different streams + +Rule 22.4 Mandatory +There shall be no attempt to write to a stream which has been opened +as read-only + +Rule 22.5 Mandatory +A pointer to a FILE object shall not be dereferenced + +Rule 22.6 Mandatory +The value of a pointer to a FILE shall not be used after the associated +stream has been closed + +Rule 22.7 Required +The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF + +Rule 22.8 Required +The value of errno shall be set to zero prior to a call to an errno-setting-function + +Rule 22.9 Required +The value of errno shall be tested against zero after calling an errno-setting-function + +Rule 22.10 Required +The value of errno shall only be tested when the last function to be called was an errno-setting-function