Software Quality Objective Subsets (C:2004)
Note
Starting in a future release, Code Prover will not support checking compliance with external coding standards and calculating code metrics. Migrate to Bug Finder for these workflows. See Software Quality Objective Subsets (C:2004).
Rules in SQO-Subset1
The SQO subset1 consists of these rules:
Rule number | Description |
---|---|
5.2 | Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier. |
8.11 | The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage. |
8.12 | When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisation. |
11.2 | Conversion shall not be performed between a pointer to an object and any type other than an integral type, another pointer to object type or a pointer to void. |
11.3 | A cast should not be performed between a pointer type and an integral type. |
12.12 | The underlying bit representations of floating-point values shall not be used. |
13.3 | Floating-point expressions shall not be tested for equality or inequality. |
13.4 | The controlling expression of a for statement shall not contain any objects of floating type. |
13.5 | The three expressions of a for statement shall be concerned only with loop control. |
14.4 | The goto statement shall not be used. |
14.7 | A function shall have a single point of exit at the end of the function. |
16.1 | Functions shall not be defined with variable numbers of arguments. |
16.2 | Functions shall not call themselves, either directly or indirectly. |
16.7 | A pointer parameter in a function prototype should be declared as pointer to const if the pointer is not used to modify the addressed object. |
17.3 | >, >=, <, <= shall not be applied to pointer types except where they point to the same array. |
17.4 | Array indexing shall be the only allowed form of pointer arithmetic. |
17.5 | The declaration of objects should contain no more than 2 levels of pointer indirection. |
17.6 | The address of an object with automatic storage shall not be assigned to an object that may persist after the object has ceased to exist. |
18.4 | Unions shall not be used. |
20.4 | Dynamic heap memory allocation shall not be used. |
Rules in SQO-Subset2
Good design practices generally lead to less code complexity. The following set of coding rules enforce good design practices. The SQO-subset2
option checks the rules in SQO-subset1
and some additional rules.
Rule number | Description |
---|---|
5.2 | Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier. |
6.3 | Typedefs that indicate size and signedness should be used in place of the basic types. |
8.7 | Objects shall be defined at block scope if they are only accessed from within a single function. |
8.11 | The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage. |
8.12 | When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisation. |
9.2 | Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures. |
9.3 | In an enumerator list, the '=' construct shall not be used to explicitly initialise members other than the first, unless all items are explicitly initialised. |
10.3 | The value of a complex expression of integer type may only be cast to a type that is narrower and of the same signedness as the underlying type of the expression. |
10.5 | If the bitwise operator ~ and << are applied to an operand of underlying type unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand. |
11.1 | Conversion shall not be performed between a pointer to a function and any type other than an integral type. |
11.2 | Conversion shall not be performed between a pointer to an object and any type other than an integral type, another pointer to object type or a pointer to void. |
11.3 | A cast should not be performed between a pointer type and an integral type. |
11.5 | A cast shall not be performed that removes any const or volatile qualification from the type addressed by a pointer. |
12.1 | Limited dependence should be placed on C's operator precedence rules in expressions. |
12.2 | The value of an expression shall be the same under any order of evaluation that the standard permits. |
12.5 | The operands of a logical && or || shall be primary-expressions. |
12.6 | The operands of a logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || and !). |
12.9 | The unary minus operator shall not be applied to an expression whose underlying type is unsigned. |
12.10 | The comma operator shall not be used. |
12.12 | The underlying bit representations of floating-point values shall not be used. |
13.1 | Assignment operators shall not be used in expressions that yield a Boolean value. |
13.2 | Tests of a value against zero should be made explicit, unless the operand is effectively Boolean. |
13.3 | Floating-point expressions shall not be tested for equality or inequality. |
13.4 | The controlling expression of a for statement shall not contain any objects of floating type. |
13.5 | The three expressions of a for statement shall be concerned only with loop control. |
13.6 | Numeric variables being used within a for loop for iteration counting should not be modified in the body of the loop. |
14.4 | The goto statement shall not be used. |
14.7 | A function shall have a single point of exit at the end of the function. |
14.8 | The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement. |
14.10 | All if ... else if constructs should contain a final else clause. |
15.3 | The final clause of a switch statement shall be the default clause. |
16.1 | Functions shall not be defined with variable numbers of arguments. |
16.2 | Functions shall not call themselves, either directly or indirectly. |
16.3 | Identifiers shall be given for all of the parameters in a function prototype declaration. |
16.7 | A pointer parameter in a function prototype should be declared as pointer to const if the pointer is not used to modify the addressed object. |
16.8 | All exit paths from a function with non-void return type shall have an explicit return statement with an expression. |
16.9 | A function identifier shall only be used with either a preceding &, or with a parenthesised parameter list, which may be empty. |
17.3 | >, >=, <, <= shall not be applied to pointer types except where they point to the same array. |
17.4 | Array indexing shall be the only allowed form of pointer arithmetic. |
17.5 | The declaration of objects should contain no more than 2 levels of pointer indirection. |
17.6 | The address of an object with automatic storage shall not be assigned to an object that may persist after the object has ceased to exist. |
18.4 | Unions shall not be used. |
19.4 | C macros shall only expand to a braced initialiser, a constant, a parenthesised expression,a type qualifier, a storage class specifier, or a do-while-zero construct. |
19.9 | Arguments to a function-like macro shall not contain tokens that look like pre-processing directives. |
19.10 | In the definition of a function-like macro each instance of a parameter shall be enclosed in parentheses unless it is used as the operand of # or ##. |
19.11 | All macro identifiers in preprocessor directives shall be defined before use, except in #ifdef and #ifndef preprocessor directives and the defined() operator. |
19.12 | There shall be at most one occurrence of the # or ## pre-processor operators in a single macro definition. |
20.3 | The validity of values passed to library functions shall be checked. |
20.4 | Dynamic heap memory allocation shall not be used. |
Note
Polyspace® software does not check MISRA™ rule 20.3 directly.
However, you can check this rule by writing manual stubs that check the validity of values. For example, the following code checks the validity of an input being greater than 1:
int my_system_library_call(int in) {assert (in>1); if random \ return -1 else return 0; }