| arithOperationsOnVoidPointer | varname’ is of type ‘vartype’. When using void pointers in calculations the behaviour is undefined. Arithmetic operations on ‘void *’ is a GNU C extension which defines the ‘sizeof(void)’ to be 1. | Robustness |
| AssignmentAddressToInteger | Assigning a pointer to an integer (int/long/etc) is not portable across different platforms and compilers. For example in 32-bit Windows and linux they are same width but in 64-bit Windows and linux they are of different width. In worst case you end up assigning 64-bit address to 32-bit integer. The safe way is to store addresses only in pointer types (or typedefs like uintptr_t). | Portability |
| AssignmentIntegerToAddress | Assigning an integer (int/long/etc) to a pointer is not portable across different platforms and compilers. For example in 32-bit Windows and linux they are same width but in 64-bit Windows and linux they are of different width. In worst case you end up assigning 64-bit integer to 32-bit pointer. The safe way is to store addresses only in pointer types (or typedefs like uintptr_t). | Portability |
| CastAddressToIntegerAtReturn | Returning an address value in a function with integer (int/long/etc) return type is not portable across different platforms and compilers. For example in 32-bit Windows and Linux they are same width but in 64-bit Windows and Linux they are of different width. In worst case you end up casting 64-bit address down to 32-bit integer. The safe way is to always return an integer. | Portability |
| CastIntegerToAddressAtReturn | Returning an integer (int/long/etc) in a function with pointer return type is not portable across different platforms and compilers. For example in 32-bit Windows and Linux they are same width but in 64-bit Windows and Linux they are of different width. In worst case you end up casting 64-bit integer down to 32-bit pointer. The safe way is to always return a pointer. | Portability |
| fflushOnInputStream | fflush() called on input stream ‘stdin’ may result in undefined behaviour on non-linux systems. | Portability |
| functionStatic | The member function ‘class::function’ can be made a static function. Making a function static can bring a performance benefit since no ‘this’ instance is passed to the function. This change should not cause compiler errors but it does not necessarily make sense conceptually. Think about your design and the task of the function first – is it a function that must not access members of class instances? | Efficiency |
| invalidPointerCast | Casting between float* and double* which have an incompatible binary data representation. | Portability |
| memsetClassFloat | Using memset() on class which contains a floating point number. This is not portable because memset() sets each byte of a block of memory to a specific value and the actual representation of a floating-point value is implementation defined. Note: In case of an IEEE754-1985 compatible implementation setting all bits to zero results in the value 0.0. | Portability |
| memsetFloat | The 2nd memset() argument ‘varname’ is a float its representation is implementation defined. memset() is used to set each byte of a block of memory to a specific value and the actual representation of a floating-point value is implementation defined. | Portability |
| passedByValue | Parameter ‘parametername’ is passed by value. It could be passed as a (const) reference which is usually faster and recommended in C++. | Efficiency |
| pointerOutOfBounds | Undefined behaviour pointer arithmetic ” is out of bounds. From chapter 6.5.6 in the C specification:12When an expression that has integer type is added to or subtracted from a pointer ..” and then “If both the pointer operand and the result point to elements of the same array object or one past the last element of the array object the evaluation shall not produce an overflow | Portability |
| postfixOperator | Prefix ++/– operators should be preferred for non-primitive types. Pre-increment/decrement can be more efficient than post-increment/decrement. Post-increment/decrement usually involves keeping a copy of the previous value around and adds a little extra code. | Efficiency |
| redundantCopy | Buffer ‘var’ is being written before its old content has been used. | Maintainability |
| redundantCopyLocalConst | The const variable ‘varname’ is assigned a copy of the data. You can avoid the unnecessary data copying by converting ‘varname’ to const reference. | Resource Utilization |
| shiftNegativeLHS | Shifting a negative value is technically undefined behaviour | Robustness |
| sizeofDereferencedVoidPointer | *varname’ is of type ‘void’ the behaviour of ‘sizeof(void)’ is not covered by the ISO C standard. A value for ‘sizeof(void)’ is defined only as part of a GNU C extension which defines ‘sizeof(void)’ to be 1. | Robustness |
| sizeofVoid | Behaviour of ‘sizeof(void)’ is not covered by the ISO C standard. A value for ‘sizeof(void)’ is defined only as part of a GNU C extension which defines ‘sizeof(void)’ to be 1. | Robustness |
| stlcstrParam | The conversion from const char* as returned by c_str() to std::string creates an unnecessary string copy. Solve that by directly passing the string. | Efficiency |
| stlcstrReturn | The conversion from const char* as returned by c_str() to std::string creates an unnecessary string copy. Solve that by directly returning the string. | Efficiency |
| stlIfStrFind | Either inefficient or wrong usage of string::find(). string::compare() will be faster if string::find’s result is compared with 0 because it will not scan the whole string. If your intention is to check that there are no findings in the string you should compare with std::string::npos. | Efficiency |
| stlSize | Checking for ‘list’ emptiness might be inefficient. Using list.empty() instead of list.size() can be faster. list.size() can take linear time but list.empty() is guaranteed to take constant time. | Efficiency |
| unknownSignCharArrayIndex | char’ type used as array index. Values greater that 127 will be treated depending on whether ‘char’ is signed or unsigned on target platform. | Robustness |
| useInitializationList | When an object of a class is created the constructors of all member variables are called consecutively in the order the variables are declared even if you don’t explicitly write them to the initialization list. You could avoid assigning ‘variable’ a value by passing the value to the constructor in the initialization list. | Efficiency |
| uselessCallsSubstr | Ineffective call of function ‘substr’ because it returns a copy of the object. Use operator= instead. | Accuracy |
| uselessCallsSwap | The ‘swap()’ function has no logical effect when given itself as parameter (str.swap(str)). As it is currently the code is inefficient. Is the object or the parameter wrong here? | Efficiency |
| varFuncNullUB | Passing NULL after the last typed argument to a variadic function leads to undefined behaviour.12The C99 standard in section 7.15.1.1 states that if the type used by va_arg() is not compatible with the type of the actual next argument (as promoted according to the default argument promotions) the behavior is undefined.12The value of the NULL macro is an implementation-defined null pointer constant (7.17) which can be any integer constant expression with the value 0 or such an expression casted to (void*) (6.3.2.3). This includes values like 0 0L or even 0LL.12In practice on common architectures this will cause real crashes if sizeof(int) != sizeof(void*) and NULL is defined to 0 or any other null pointer constant that promotes to int.12To reproduce you might be able to use this little code example on 64bit platforms. If the output includes ERROR” the sentinel had only 4 out of 8 bytes initialized to zero and was not detected as the final argument to stop argument processing via va_arg(). Changing the 0 to (void*)0 or 0L will make the “ERROR” output go away.12#include 12#include 1212void f(char *s …) {12 va_list ap | Robustness |
| misra-c2012-1.3 | There shall be no occurrence of undefined or critical unspecified behavior | Robustness |
| misra-c2012-2.1 | A project shall not contain unreachable code | Robustness |
| misra-c2012-2.2 | There shall be no dead code | Robustness |
| misra-c2012-2.4 | A project should not contain unused tag declarations | Robustness |
| misra-c2012-2.6 | A function should not contain unused label declarations | Robustness |
| misra-c2012-3.1 | The character sequences /* an // shall not be used within a comment | Robustness |
| misra-c2012-4.1 | Octal and hexadecimal escape sequences shall be terminated | Robustness |
| misra-c2012-5.1 | External identifiers shall be distinct | Robustness |
| misra-c2012-5.3 | An identifier declared in an inner scope shall not hide an identifier declared in an outer scope | Robustness |
| misra-c2012-5.4 | Macro identifiers shall be distinct | Robustness |
| misra-c2012-5.5 | Identifiers shall be distinct from macro names | Robustness |
| misra-c2012-7.1 | Octal constants shall not be used | Robustness |
| misra-c2012-7.3 | The lowercase character ‘l’ shall not be used in a literal suffix | Robustness |
| misra-c2012-8.3 | All declarations of an object or function shall use the same names and type qualifiers | Robustness |
| misra-c2012-8.11 | When an array with external linkage is declared, its size should be explicitly specified | Robustness |
| misra-c2012-8.12 | Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique | Robustness |
| misra-c2012-8.14 | The restrict type qualifier shall not be used | Robustness |
| misra-c2012-9.1 | The value of an object with automatic storage duration shall not be read before it has been set | Robustness |
| misra-c2012-9.5 | Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly | Robustness |
| misra-c2012-10.4 | Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category | Robustness |
| misra-c2012-10.6 | The value of a composite expression shall not be assigned to an object with wider essential type | Robustness |
| misra-c2012-10.8 | The value of a composite expression shall not be cast to a different essential type category or a wider essential type | Robustness |
| misra-c2012-11.3 | A cast shall not be performed between a pointer to object type and a pointer to a different object type | Robustness |
| misra-c2012-11.4 | A conversion should not be performed between a pointer to object and an integer type | Robustness |
| misra-c2012-11.5 | A conversion should not be performed from pointer to void into pointer to object | Robustness |
| misra-c2012-11.6 | A cast shall not be performed between pointer to void and an arithmetic type | Robustness |
| misra-c2012-11.7 | A cast shall not be performed between pointer to object and a noninteger arithmetic type | Robustness |
| misra-c2012-11.8 | A cast shall not remove any const or volatile qualification from the type pointed to by a pointer | Robustness |
| misra-c2012-11.9 | The macro NULL shall be the only per mitted form of integer null pointer constant | Robustness |
| misra-c2012-12.1 | The precedence of operators within expressions should be made explicit | Robustness |
| misra-c2012-12.2 | 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 | Robustness |
| misra-c2012-12.3 | The comma operator should not be used | Robustness |
| misra-c2012-12.4 | Evaluation of constant expressions should not lead to unsigned integer wrap-around | Robustness |
| misra-c2012-13.1 | Initializer lists shall not contain persistent side effects | Robustness |
| misra-c2012-13.2 | The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders | Robustness |
| misra-c2012-13.3 | 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 | Robustness |
| misra-c2012-13.4 | The result of an assignment operator should not be used | Robustness |
| misra-c2012-13.5 | The right-hand operand of a logical && or || operator shall not contain persistent side effects | Robustness |
| misra-c2012-13.6 | The operand of the sizeof operator shall not contain any expression which has potential side effects | Robustness |
| misra-c2012-14.1 | A loop counter shall not have essentially floating type | Robustness |
| misra-c2012-14.2 | A for loop shall be well-formed | Robustness |
| misra-c2012-14.4 | The controlling expression of an if statement and the controlling expression of an iteration- statement shall have essentially Boolean type | Robustness |
| misra-c2012-15.1 | The goto statement should not be used | Robustness |
| misra-c2012-15.2 | The goto statement shall jump to a label declared later in the same function | Robustness |
| misra-c2012-15.3 | Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement | Robustness |
| misra-c2012-15.5 | A function should have a single point of exit at the end | Robustness |
| misra-c2012-15.6 | The body of an iteration-statement or a selection-statement shall be a compound-statement | Robustness |
| misra-c2012-15.7 | All if … else if constructs shall be terminated with an else statement | Robustness |
| misra-c2012-16.2 | A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement | Robustness |
| misra-c2012-16.3 | An unconditional break statement shall terminate every switch-clause | Robustness |
| misra-c2012-16.4 | Every switch statement shall have a default label | Robustness |
| misra-c2012-16.5 | A default label shall appear as either the first or the last switch label of a switch statement | Robustness |
| misra-c2012-16.6 | Every switch statement shall have at least two switch-clauses | Robustness |
| misra-c2012-16.7 | A switch-expression shall not have essentially Boolean type | Robustness |
| misra-c2012-17.1 | The features of shall not be used | Robustness |
| misra-c2012-17.5 | The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements | Robustness |
| misra-c2012-17.6 | The declaration of an array parameter shall not contain the static keyword between the [ ] | Robustness |
| misra-c2012-17.8 | A function parameter should not be modified | Robustness |
| misra-c2012-18.1 | A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand | Robustness |
| misra-c2012-18.5 | Declarations should contain no more than two levels of pointer nesting | Robustness |
| misra-c2012-18.6 | 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 | Robustness |
| misra-c2012-18.8 | Variable-length array types shall not be used | Robustness |
| misra-c2012-19.2 | The union keyword should not be used | Robustness |
| misra-c2012-20.1 | #include directives should only be preceded by preprocessor directives or comments | Robustness |
| misra-c2012-20.2 | The ‘, ” or characters and the /* or // character sequences shall not occur in a header fi le name | Robustness |
| misra-c2012-20.3 | The #include directive shall be followed by either a or “filename” sequence | Robustness |
| misra-c2012-20.4 | A macro shall not be defined with the same name as a keyword | Robustness |
| misra-c2012-20.5 | #undef should not be used | Robustness |
| misra-c2012-21.3 | The memory allocation and deallocation functions of shall not be used | Robustness |
| misra-c2012-21.4 | The standard header file shall not be used | Robustness |
| misra-c2012-21.5 | The standard header file shall not be used | Robustness |
| misra-c2012-21.7 | The atof, atoi, atol and atoll functions of shall not be used | Robustness |
| misra-c2012-21.8 | The library functions abort, exit, getenv and system of shall not be used | Robustness |
| misra-c2012-21.9 | The library functions bsearch and qsort of shall not be used | Robustness |
| misra-c2012-21.11 | The standard header file shall not be used | Robustness |
| misra-c2012-22.1 | All resources obtained dynamically by means of Standard Library functions shall be explicitly released | Robustness |
| misra-c2012-22.2 | A block of memory shall only be freed if it was allocated by means of a Standard Library function | Robustness |
| misra-c2012-22.4 | There shall be no attempt to write to a stream which has been opened as read-only | Robustness |
| misra-c2012-22.6 | The value of a pointer to a FILE shall not be used after the associated stream has been closed | Robustness |
