Polyspace Support for MISRA C: 2012 Technical Corrigenda and Amendments

Starting in R2021a, Polyspace^® Bug Finder™ supports amendments to MISRA C™:2012 rules in Technical Corrigendum 1, Technical Corrigendum 2, Amendment 1, Amendment 2, and Amendment 3.

MISRA C:2012 Technical Corrigendum 1

MISRA C:2012 Technical Corrigendum 1 adds clarifications to existing rules. The clarifications have led to corresponding changes in the Polyspace checkers.

Rule	Description	Update in Technical Corrigendum 1
`MISRA C:2012 Rule 10.1`	Operands shall not be of an inappropriate essential type.	The rule now explicitly forbids use of pointer types with logical operands such as `&&`, `\|\|` and `!`.
`MISRA C:2012 Rule 10.5`	The value of an expression should not be cast to an inappropriate essential type.	The rule now forbids casts of integer constants with value 0 or 1 to essentially enum types.
`MISRA C:2012 Rule 11.2`	Conversions shall not be performed between a pointer to an incomplete type and any other type.	The rule now takes into account only the unqualified types that the pointers point to. For instance, if a pointer is assigned to another and the only difference between the pointed types is a `const` qualifier, the rule does not consider this assignment as a conversion.
`MISRA C:2012 Rule 11.4`	A conversion should not be performed between a pointer to object and an integer type.	The rule now applies explicitly to pointers to objects only. Conversions between an integer type and other pointer types such as `void*` or pointers to functions are flagged by other rules.
`MISRA C:2012 Rule 11.9`	The macro NULL shall be the only permitted form of integer null pointer constant.	The rule allows the use of `{0}` to initialize aggregates or unions containing pointers.
`MISRA C:2012 Rule 14.2`	A for loop shall be well-formed.	The rule allows any form of initialization of the loop counter as long as the initialization does not have other side effects.

MISRA C:2012 Technical Corrigendum 2

MISRA C:2012 Technical Corrigendum 2 adds clarifications to existing rules. The clarifications have led to corresponding changes in these Polyspace checkers:

Rule	Description	Update in Technical Corrigendum 2
`MISRA C:2012 Rule 2.5`	A project should not contain unused macro definitions	The title of the rule is changed. The word 'declarations' is replaced by 'definitions'.
`MISRA C:2012 Rule 10.2`	Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations	Polyspace now reports violations of this rule if you use `long` or `long long` type variables in an arithmetic operation with `char` type variables.
`MISRA C:2012 Rule 13.6`	The operand of the sizeof operator shall not contain any expression which has potential side effects	Starting in R2023b, this rule is Required instead of Mandatory.
`MISRA C:2012 Rule 17.4`	All exit paths from a function with non-void return type shall have an explicit return statement with an expression	Starting in R2023b, Polyspace does not report a violation if the `main()` function of C99 or later C code lacks an explicit `return` statement.
`MISRA C:2012 Rule 17.5`	The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements	Starting in R2023b, this rule is Required instead of Advisory.

MISRA C: 2012 Amendment 1 (AMD1)

MISRA C:2012 Amendment 1 introduces new coding rules that prevent security vulnerabilities.

Rule	Description
`MISRA C:2012 Dir 4.14`	The validity of values received from external sources shall be checked.
`MISRA C:2012 Rule 12.5`	The `sizeof` operator shall not have an operand which is a function parameter declared as "array of type".
`MISRA C:2012 Rule 21.13`	Any value passed to a function in `<ctype.h>` shall be representable as an `unsigned char` or be the value EOF.
`MISRA C:2012 Rule 21.14`	The Standard Library function `memcmp` shall not be used to compare null terminated strings.
`MISRA C:2012 Rule 21.15`	The pointer arguments to the Standard Library functions `memcpy`, `memmove` and `memcmp` shall be pointers to qualified or unqualified versions of compatible types.
`MISRA C:2012 Rule 21.16`	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.
`MISRA C:2012 Rule 21.17`	Use of the string handling function from `<string.h>` shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters.
`MISRA C:2012 Rule 21.18`	The `size_t` argument passed to any function in `<string.h>` shall have an appropriate value.
`MISRA C:2012 Rule 21.19`	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.
`MISRA C:2012 Rule 21.20`	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.
`MISRA C:2012 Rule 22.7`	The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF.
`MISRA C:2012 Rule 22.8`	The value of `errno` shall be set to zero prior to a call to an `errno`-setting-function.
`MISRA C:2012 Rule 22.9`	The value of `errno` shall be tested against zero after calling an `errno`-setting function.
`MISRA C:2012 Rule 22.10`	The value of `errno` shall only be tested when the last function to be called was an `errno`-setting function.

MISRA C:2012 Amendment 1 introduced changes to existing rules:

Rule Description Change

Rule	Description	Change
`MISRA C:2012 Rule 21.8`	The Standard Library termination functions of `<stdlib.h>` shall not be used	References to `getenv` is removed from rule headline and amplification. After the introduction of 21.19 and 21.20, using `getenv` in 21.8 is no longer necessary.

MISRA C:2012 Rule
                  21.8

The Standard Library termination functions of <stdlib.h> shall not be used

References to getenv is removed from rule headline and amplification.

After the introduction of 21.19 and 21.20, using getenv in 21.8 is no longer necessary.

MISRA C:2012 Amendment 2 (AMD2)

MISRA C:2012 Amendment 2 addresses the new language features in the ISO^®/IEC 9899:2011 (C11) standard. All updates in Amendment 2 have been incorporated in the Polyspace checkers.

Rule	Description	Update in Amendment 2
`MISRA C:2012 Rule 1.4`	Emergent language features shall not be used.	This rule is new in Amendment 2.
`MISRA C:2012 Rule 12.1`	The precedence of operators within expressions should be made explicit.	The rule now mandates a violation if the operand of the `_Alignof` operator is not enclosed in parenthesis.
`MISRA C:2012 Rule 21.3`	The memory allocation and deallocation functions of `<stdlib.h>` shall not be used.	The rule now flags uses of the `aligned_alloc` function.
`MISRA C:2012 Rule 21.8`	The Standard Library termination functions of <stdlib.h> shall not be used.	The rule no longer flags `system`. In addition to `exit` and `abort`, the rule now flags `_Exit` and `quick_exit`.
`MISRA C:2012 Rule 21.21`	The Standard Library function `system` of `<stdlib.h>` shall not be used.	This rule is new in Amendment 2.
`MISRA C:2012 Rule 22.1`	All resources obtained dynamically by means of Standard Library functions shall be explicitly released.	The rule now flags memory allocation using the `aligned_alloc` function if the memory is not released.

MISRA C:2012 Amendment 3 (AMD3)

Since R2024a

MISRA C:2012 Amendment 3 addresses language features in the ISO/IEC 9899:2011 (C11) and ISO/IEC 9899:2018 (C17/C18) standards.

Rules Introduced in MISRA C:2012 Amendment 3 (AMD3)

Amendment 3 adds these rules and directives to address language features in C11 and C18:

Rule	Description
`MISRA C:2012 Dir 4.15`	Evaluation of floating-point expressions shall not lead to the undetected generation of infinities and NaNs.
`MISRA C:2012 Rule 1.5`	Obsolescent language features shall not be used.
`MISRA C:2012 Rule 6.3`	A bit field shall not be declared as a member of a union.
`MISRA C:2012 Rule 7.5`	The argument of an integer constant macro shall have an appropriate form.
`MISRA C:2012 Rule 8.15`	All declarations of an object with an explicit alignment specification shall specify the same alignment.
`MISRA C:2012 Rule 8.16`	The alignment specification of zero should not appear in an object declaration.
`MISRA C:2012 Rule 8.17`	At most one explicit alignment specifier should appear in an object declaration.
`MISRA C:2012 Rule 17.9`	A function declared with a `_Noreturn` function specifier shall not return to its caller.
`MISRA C:2012 Rule 17.10`	A function declared with a `_Noreturn` function specifier shall have void return type.
`MISRA C:2012 Rule 17.11`	A function that never returns should be declared with a `_Noreturn` function specifier.
`MISRA C:2012 Rule 17.12`	A function identifier should only be used with either a preceding `&`, or with a parenthesized parameter list.
`MISRA C:2012 Rule 17.13`	A function type shall not be type qualified.
`MISRA C:2012 Rule 18.9`	An object with temporary lifetime shall not undergo array-to-pointer conversion.
`MISRA C:2012 Rule 21.22`	All operand arguments to any type-generic macros declared in `<tgmath.h>` shall have an appropriate essential type.
`MISRA C:2012 Rule 21.23`	All operand arguments to any multi-argument type-generic macros declared in `<tgmath.h>` shall have the same standard type.
`MISRA C:2012 Rule 21.24`	The random number generator functions of `<stdlib.h>` shall not be used.
`MISRA C:2012 Rule 23.1`	A generic selection should only be expanded from a macro.
`MISRA C:2012 Rule 23.2`	A generic selection that is not expanded from a macro shall not contain potential side effects in the controlling expression.
`MISRA C:2012 Rule 23.3`	A generic selection should contain at least one non-default association.
`MISRA C:2012 Rule 23.4`	A generic association shall list an appropriate type.
`MISRA C:2012 Rule 23.5`	A generic selection should not depend on implicit pointer type conversion.
`MISRA C:2012 Rule 23.6`	The controlling expression of a generic selection shall have an essential type that matches its standard type.
`MISRA C:2012 Rule 23.7`	A generic selection that is expanded from a macro should evaluate its argument only once.
`MISRA C:2012 Rule 23.8`	A default association shall appear as either the first or the last association of a generic selection.

Rules Modified in MISRA C:2012 Amendment 3 (AMD3)

Amendment 3 modifies these existing rules and directives to accommodate C11 and C18 features:

Rule	Purpose of Change
`MISRA C:2012 Dir 4.6`	Polyspace reports a violation if `typedefs` for essentially complex floating types fail to indicate size and signedness.
`MISRA C:2012 Dir 4.9`	The directive now allows function-like macros when they are used for generic selection.
`MISRA C:2012 Dir 4.11`	Polyspace reports a violation if the periodic trigonometric functions in `math.h` are invoked using values outside the range `[-π,π]`.
`MISRA C:2012 Rule 1.4`	The rule now allows the use of these features: The `_Generic` operator The `_Noreturn` specifier The `<stdnoreturn.h>` header file The `_Alignas` alignment specifier The `_Alignof` operator The `<stdalign.h>` header file
`MISRA C:2012 Rule 10.1`	Polyspace reports a violation on comparison of real and complex floating-point types.
`MISRA C:2012 Rule 10.3`	Polyspace reports no violations for appropriate assignments of essentially real floating types to essentially complex floating types.
`MISRA C:2012 Rule 10.4`	The rule now supports complex essential types.
`MISRA C:2012 Rule 10.5`	Polyspace reports a violation on inappropriate conversion to and from essentially complex floating types.
`MISRA C:2012 Rule 10.7`	The rule now supports complex essential types.
`MISRA C:2012 Rule 10.8`	Polyspace reports a violation when complex numbers are cast to wider essential types or cast from narrower essential types.
`MISRA C:2012 Rule 11.7`	The rule now supports complex essential types.
`MISRA C:2012 Rule 21.11`	The rule is now categorized as Advisory.
`MISRA C:2012 Rule 21.12`	The rule is now categorized as Required.

MISRA C:2012 Amendment 4 (AMD4)

Since R2024b

MISRA C:2012 Amendment 4 addresses concurrency features in the ISO/IEC 9899:2011 (C11) and ISO/IEC 9899:2018 (C17/C18) standards.

Rules Introduced in MISRA C:2012 Amendment 4 (AMD4)

Polyspace supports these rules from the Amendment 4:

Rule or Directive	Description
`MISRA C:2012 Dir 5.1`	There shall be no data races between threads.
`MISRA C:2012 Dir 5.2`	There shall be no deadlocks between threads.
`MISRA C:2012 Rule 22.11`	A thread that was previously either joined or detached shall not be subsequently joined nor detached.
`MISRA C:2012 Rule 22.15`	Thread synchronization objects and thread-specific storage pointers shall not be destroyed until after all threads accessing them have terminated.
`MISRA C:2012 Rule 22.16`	All mutex objects locked by a thread shall be explicitly unlocked by the same thread.
`MISRA C:2012 Rule 22.17`	No thread shall unlock a mutex or call `cnd_wait()` or `cnd_timedwait()` for a mutex it has not locked before.

Rules Modified in MISRA C:2012 Amendment 4 (AMD4)

Amendment 4 modifies these existing rules and directives:

Rule or Directive	Description of Change
`MISRA C:2012 Rule 2.2`	The rule definition is changed to "A project shall not contain dead code".
`MISRA C:2012 Rule 2.7`	The rule definition is changed to "A function should not contain unused parameters".
`MISRA C:2012 Rule 8.9`	The rule definition is changed to "An object should be declared at block scope if its identifier only appears in a single function".
`MISRA C:2012 Rule 11.3`	The rule definition is changed to "A conversion shall not be performed between a pointer to object type and a pointer to a different object type".
`MISRA C:2012 Rule 11.8`	The rule is extended to cover the `_Atomic` qualification. The rule definition is changed to "A conversion shall not remove any `const`, `volatile` or `_Atomic` qualification from the type pointed to by a pointer".
`MISRA C:2012 Rule 13.2`	The rule is extended to cover concurrency aspects. The rule definition is changed to "The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders and shall be independent from thread interleaving".
`MISRA C:2012 Rule 18.3`	The rule now applies to expressions of pointer type instead of objects of pointer type. The rule definition is changed to "The relational operators >, >=, < and <= shall not be applied to expressions of pointer type except where they point into the same object".
`MISRA C:2012 Rule 18.6`	The rule is extended to thread-local objects. The rule definition is changed to "The address of an object with automatic or thread-local storage shall not be copied to another object that persists after the first object has ceased to exist".
`MISRA C:2012 Rule 18.8`	The rule is limited to variable length arrays only. The rule definition is changed to "Variable-length arrays shall not be used".