Rule ID | Header |
|---|
AUTOSAR-M5_2_9-b | A conversion should not be performed from a pointer type to an arithmetic type |
CODSTA-128_b | A conversion should not be performed from pointer to void into pointer to object |
CODSTA-223_d | The names of standard floating-point types should not be used |
CODSTA-245 | Tentative definitions should not be placed in a header file |
CODSTA-246 | Objects with external linkage should be declared at file scope |
CODSTA-247 | Functions with external linkage should not be declared in implementation files |
CODSTA-318 | Passing an argument to a function's ellipsis parameter should not implicitly change the argument's type |
CODSTA-319 | The use of the 'assert' macro should not result in a call to the 'abort' function |
CODSTA-320 | Pointers shall not be implicitly compared to NULL |
CODSTA-321 | A conversion should not be performed from an arithmetic type to a pointer type |
CODSTA-322 | A conversion should not be performed from a pointer type to an arithmetic type |
CODSTA-CPP-214 | The argument and the parameter of a function call should have the same type if the parameter is not overload-independent |
CWE-121-a | Avoid accessing arrays out of bounds |
CWE-121-b | Avoid accessing arrays and pointers out of bounds |
CWE-121-c | Avoid buffer overflow due to defining incorrect format limits |
CWE-121-d | Avoid overflow when reading from a buffer |
CWE-121-e | Avoid overflow when writing to a buffer |
CWE-121-f | Avoid tainted data in array indexes |
CWE-121-g | Prevent buffer overflows from tainted data |
CWE-121-h | Avoid buffer read overflow from tainted data |
CWE-121-i | Avoid buffer write overflow from tainted data |
CWE-121-j | Suspicious use of 'strcpy' without checking size of source buffer |
CWE-121-k | Ensure the output buffer is large enough when using path manipulation functions |
CWE-121-l | Avoid accessing collections out of bounds |
CWE-122-a | Avoid accessing arrays out of bounds |
CWE-122-b | Avoid accessing arrays and pointers out of bounds |
CWE-122-c | Avoid buffer overflow due to defining incorrect format limits |
CWE-122-d | Avoid overflow when reading from a buffer |
CWE-122-e | Avoid overflow when writing to a buffer |
CWE-122-f | Avoid tainted data in array indexes |
CWE-122-g | Prevent buffer overflows from tainted data |
CWE-122-h | Avoid buffer read overflow from tainted data |
CWE-122-i | Avoid buffer write overflow from tainted data |
CWE-122-j | Suspicious use of 'strcpy' without checking size of source buffer |
CWE-122-k | Ensure the output buffer is large enough when using path manipulation functions |
CWE-122-l | Avoid accessing collections out of bounds |
CWE-124-a | Avoid accessing arrays out of bounds |
CWE-124-b | Avoid accessing arrays and pointers out of bounds |
CWE-124-c | Avoid buffer overflow due to defining incorrect format limits |
CWE-124-d | Avoid overflow when writing to a buffer |
CWE-124-e | Avoid tainted data in array indexes |
CWE-124-f | Prevent buffer overflows from tainted data |
CWE-124-g | Avoid buffer write overflow from tainted data |
CWE-124-h | Suspicious use of 'strcpy' without checking size of source buffer |
CWE-124-i | Ensure the output buffer is large enough when using path manipulation functions |
CWE-124-j | Avoid accessing collections out of bounds |
CWE-126-a | Avoid accessing arrays out of bounds |
CWE-126-b | Avoid accessing arrays and pointers out of bounds |
CWE-126-c | Avoid buffer overflow due to defining incorrect format limits |
CWE-126-d | Avoid overflow when reading from a buffer |
CWE-126-e | Avoid tainted data in array indexes |
CWE-126-f | Avoid buffer read overflow from tainted data |
CWE-126-g | Suspicious use of 'strcpy' without checking size of source buffer |
CWE-126-h | Ensure the output buffer is large enough when using path manipulation functions |
CWE-126-i | Avoid accessing collections out of bounds |
CWE-127-a | Avoid accessing arrays out of bounds |
CWE-127-b | Avoid accessing arrays and pointers out of bounds |
CWE-127-c | Avoid buffer overflow due to defining incorrect format limits |
CWE-127-d | Avoid overflow when reading from a buffer |
CWE-127-e | Avoid tainted data in array indexes |
CWE-127-f | Avoid buffer read overflow from tainted data |
CWE-127-g | Suspicious use of 'strcpy' without checking size of source buffer |
CWE-127-h | Ensure the output buffer is large enough when using path manipulation functions |
CWE-127-i | Avoid accessing collections out of bounds |
CWE-134-a | Exclude unsanitized user input from format strings |
CWE-188-a | Do not read the value of a non-active union field |
CWE-188-b | A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array |
CWE-191-a | Avoid wraparounds when performing arithmetic integer operations |
CWE-191-b | Avoid possible integer overflow in expressions in which the result is cast to a wider integer type |
CWE-191-c | Avoid possible integer overflow in expressions in which the result is assigned to a variable of a wider integer type |
CWE-191-d | Avoid possible integer overflow in expressions in which the result is compared to an expression of a wider integer type |
CWE-191-e | Integer overflow or underflow in constant expression in '+', '-', '*' operator |
CWE-191-f | Integer overflow or underflow in constant expression in '<<' operator |
CWE-191-g | Evaluation of constant unsigned integer expressions should not lead to wrap-around |
CWE-191-h | Avoid signed integer overflows |
CWE-191-i | Evaluation of constant unsigned integer expressions in preprocessor directives should not lead to wraparound |
CWE-191-j | Avoid data loss when converting between integer types |
CWE-191-k | Avoid potential integer overflow/underflow on tainted data |
CWE-194-a | The size_t argument passed to any function in string.h shall have an appropriate value |
CWE-194-b | Do not pass negative values to functions expecting non-negative arguments |
CWE-194-c | Avoid overflow when writing to a buffer |
CWE-195-a | Avoid potential integer overflow/underflow on tainted data |
CWE-195-b | Avoid value change when converting between integer types |
CWE-195-c | Do not pass negative values to functions expecting non-negative arguments |
CWE-196-a | Implicit conversions from wider to narrower integral type which may result in a loss of information shall not be used |
CWE-226-a | Reset strings on fgets() or fgetws() failure |
CWE-23-a | Protect against file name injection |
CWE-242-a | Never use gets() |
CWE-244-a | Sensitive data should be cleared before being deallocated |
CWE-252-a | Always check the returned value of non-void function |
CWE-338-a | The random number generator functions 'rand()' and 'srand()' should not be used |
CWE-36-a | Protect against file name injection |
CWE-364-a | Properly define signal handlers |
CWE-367-a | Avoid race conditions while checking for the existence of a symbolic link |
CWE-369-a | Avoid division by zero |
CWE-377-a | Use secure temporary file name functions |
CWE-391-a | Properly use errno value |
CWE-396-a | Avoid using catch-all exception handlers |
CWE-398-a | All non-null statements shall either have at least one side-effect however executed or cause control flow to change |
CWE-398-b | Useless 'case' and 'default' clauses should not be used |
CWE-398-c | Functions with void return type shall not be empty |
CWE-398-d | Do not assign a variable to itself |
CWE-398-e | Null statements should not be used |
CWE-398-f | Empty compound statements should not be used |
CWE-400-b | Validate potentially tainted data before it is used in the controlling expression of a loop |
CWE-404-a | Ensure resources are freed |
CWE-427-b | Protect against environment injection |
CWE-440-a | Avoid throwing exceptions from functions that are declared not to throw |
CWE-457-a | Avoid use before initialization |
CWE-459-a | Ensure resources are freed |
CWE-467-a | Do not use sizeof operator on pointer type to specify the size of the memory to be allocated via 'malloc', 'calloc' or 'realloc' function |
CWE-468-a | Do not add or subtract a scaled integer to a pointer |
CWE-469-a | Do not subtract two pointers that do not address elements of the same array |
CWE-475-a | An object shall not be assigned or copied to an overlapping object |
CWE-478-a | Always provide a default branch for switch statements |
CWE-479-a | Properly define signal handlers |
CWE-480-a | A conversion from function type to pointer-to-function type shall only occur in appropriate contexts |
CWE-481-a | The result of an assignment operator should not be used |
CWE-482-a | All non-null statements shall either have at least one side-effect however executed or cause control flow to change |
CWE-483-a | The statement forming the body of an 'if' or 'else' statement should be a compound statement |
CWE-484-a | Missing break statement between cases in a switch statement |
CWE-500-a | Avoid "public" data members |
CWE-506-a | Avoid passing sensitive data to functions that write to log files |
CWE-526-a | Avoid printing tainted data on the output console |
CWE-534-a | Avoid passing sensitive data to functions that write to log files |
CWE-535-a | Avoid passing sensitive data to functions that write to log files |
CWE-561-a | There shall be no unreachable code in "else" block |
CWE-561-b | There shall be no unreachable code after 'return', 'break', 'continue', 'goto', 'throw' statements, and after calls to functions with the 'noreturn' attribute |
CWE-561-c | There shall be no unreachable code in "if/else/while/for" block |
CWE-561-d | There shall be no unreachable code in switch statement |
CWE-561-e | There shall be no unreachable code in 'for' loop |
CWE-561-f | There shall be no unreachable code after 'if' or 'switch' statement |
CWE-561-g | There shall be no unreachable code after "if" or "switch" statement inside while/for/do...while loop |
CWE-561-h | Avoid unreachable methods |
CWE-562-a | The address of an object with automatic storage shall not be returned from a function |
CWE-563-a | Avoid unused values |
CWE-570-a | Avoid conditions that always evaluate to the same value |
CWE-571-a | Avoid conditions that always evaluate to the same value |
CWE-590-a | Do not free resources using invalid pointers |
CWE-591-a | Sensitive data should be cleared before being deallocated |
CWE-606-a | Validate potentially tainted data before it is used in the controlling expression of a loop |
CWE-665-a | Avoid overflow due to reading a not zero terminated string |
CWE-665-b | Avoid conditions that always evaluate to the same value |
CWE-667-a | Do not abandon unreleased locks |
CWE-672-a | Do not modify container while iterating over it |
CWE-674-a | Avoid infinite recursion |
CWE-675-a | Do not use resources that have been freed |
CWE-685-a | The number of format specifiers in the format string and the number of corresponding arguments in the invocation of a string formatting function should be equal |
CWE-688-a | There should be no mismatch between the '%s' and '%c' format specifiers in the format string and their corresponding arguments in the invocation of a string formatting function |
CWE-690-a | Avoid null pointer dereferencing |
CWE-758-a | Avoid use before initialization |
CWE-761-a | Do not free resources using invalid pointers |
CWE-762-a | Properly deallocate dynamically allocated resources |
CWE-773-a | Ensure resources are freed |
CWE-775-a | Ensure resources are freed |
CWE-785-a | Ensure the output buffer is large enough when using path manipulation functions |
CWE-789-a | Validate potentially tainted data before it is used to determine the size of memory allocation |
CWE-832-a | Do not release a lock that has not been acquired |
JSF-209_c | The names of the standard floating-point types should not be used |
JSF-209_d | The typedef to the standard floating-point type should contain in the name the number indicating its size |
MISRA2004-6_3_c | The names of standard floating-point types should not be used |
MISRA2004-6_3_d | A typedef for a standard floating-point type should contain the number indicating its size in its name |
MISRA2008-5_2_9_b | A cast should not convert a pointer type to an integral type |
MISRA2012-DIR-4_6_d | The names of the standard floating-point types should not be used |
MISRA2012-DIR-4_6_e | The typedef to the standard floating-point type should contain in the name the number indicating its size |
MISRA2012-RULE-10_1_i | Pointers shall not be implicitly compared to NULL |
MISRAC2012-DIR_4_6-d | The names of standard floating-point types should not be used |
MISRAC2012-DIR_4_6-e | A typedef for a standard floating-point type should contain the number indicating its size in its name |
MISRAC2012-RULE_10_1-i | Pointers shall not be implicitly compared to NULL |
MISRAC2025-DIR_4_1-a | Avoid accessing arrays out of bounds |
MISRAC2025-DIR_4_1-b | Avoid null pointer dereferencing |
MISRAC2025-DIR_4_1-c | Avoid division by zero |
MISRAC2025-DIR_4_1-d | Avoid buffer overflow due to defining incorrect format limits |
MISRAC2025-DIR_4_1-e | Avoid overflow due to reading a not zero terminated string |
MISRAC2025-DIR_4_1-g | Avoid overflow when reading from a buffer |
MISRAC2025-DIR_4_1-h | Avoid overflow when writing to a buffer |
MISRAC2025-DIR_4_1-i | Do not subtract two pointers that do not address elements of the same array |
MISRAC2025-DIR_4_1-j | Do not compare two unrelated pointers |
MISRAC2025-DIR_4_1-k | Avoid wraparounds when performing arithmetic integer operations |
MISRAC2025-DIR_4_1-l | Avoid signed integer overflows |
MISRAC2025-DIR_4_1-m | Avoid data loss when converting between integer types |
MISRAC2025-DIR_4_10-a | Use multiple include guards |
MISRAC2025-DIR_4_11-a | Validate values passed to library functions |
MISRAC2025-DIR_4_12-a | Dynamic heap memory allocation shall not be used |
MISRAC2025-DIR_4_13-a | Ensure resources are freed |
MISRAC2025-DIR_4_13-b | Do not use resources that have been freed |
MISRAC2025-DIR_4_13-c | Do not free resources using invalid pointers |
MISRAC2025-DIR_4_13-d | Do not abandon unreleased locks |
MISRAC2025-DIR_4_13-e | Avoid double locking |
MISRAC2025-DIR_4_13-f | Do not release a lock that has not been acquired |
MISRAC2025-DIR_4_14-a | Avoid tainted data in array indexes |
MISRAC2025-DIR_4_14-b | Avoid potential integer overflow/underflow on tainted data |
MISRAC2025-DIR_4_14-c | Avoid buffer read overflow from tainted data |
MISRAC2025-DIR_4_14-d | Avoid buffer write overflow from tainted data |
MISRAC2025-DIR_4_14-e | Protect against command injection |
MISRAC2025-DIR_4_14-f | Protect against file name injection |
MISRAC2025-DIR_4_14-g | Protect against SQL injection |
MISRAC2025-DIR_4_14-h | Prevent buffer overflows from tainted data |
MISRAC2025-DIR_4_14-i | Avoid buffer overflow from tainted data due to defining incorrect format limits |
MISRAC2025-DIR_4_14-j | Protect against environment injection |
MISRAC2025-DIR_4_14-k | Avoid printing tainted data on the output console |
MISRAC2025-DIR_4_14-l | Exclude unsanitized user input from format strings |
MISRAC2025-DIR_4_15-a | Do not use floating-point expressions which may result in NaN and infinity values |
MISRAC2025-DIR_4_2-a | All usage of assembler shall be documented |
MISRAC2025-DIR_4_3-a | Assembly language shall be encapsulated and isolated |
MISRAC2025-DIR_4_4-a | Sections of code should not be "commented out" |
MISRAC2025-DIR_4_4-b | Sections of code should not be "commented out" using Doxygen comments |
MISRAC2025-DIR_4_5-a | Identifiers in the same name space with overlapping visibility should be typographically unambiguous |
MISRAC2025-DIR_4_6-a | A typedef for a standard integer type should contain the number indicating its size in its name |
MISRAC2025-DIR_4_6-b | The names of standard signed integer types and standard unsigned integer types should not be used |
MISRAC2025-DIR_4_6-c | Use typedefs from stdint.h instead of declaring your own in C99 code |
MISRAC2025-DIR_4_7-a | Consistently check the returned value of non-void functions |
MISRAC2025-DIR_4_7-b | Always check the returned value of non-void function |
MISRAC2025-DIR_4_8-a | If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden |
MISRAC2025-DIR_4_9-a | A function should be used in preference to a function-like macro |
MISRAC2025-DIR_5_1-a | Do not use global variable with different locks set |
MISRAC2025-DIR_5_1-b | Variable should be used in context of single critical section |
MISRAC2025-DIR_5_1-c | There shall be no data races between threads |
MISRAC2025-DIR_5_2-a | Do not acquire locks in different order |
MISRAC2025-DIR_5_3-a | A thread should not be created by another thread |
MISRAC2025-RULE_10_1-a | An expression of essentially Boolean type should always be used where an operand is interpreted as a Boolean value |
MISRAC2025-RULE_10_1-b | An operand of essentially Boolean type should not be used where an operand is interpreted as a numeric value |
MISRAC2025-RULE_10_1-c | An operand of essentially character type should not be used where an operand is interpreted as a numeric value |
MISRAC2025-RULE_10_1-d | An operand of essentially enum type should not be used in an arithmetic operation |
MISRAC2025-RULE_10_1-e | Shift and bitwise operations should not be performed on operands of essentially signed or enum type |
MISRAC2025-RULE_10_1-f | An operand of essentially signed or enum type should not be used as the right hand operand to the bitwise shifting operator |
MISRAC2025-RULE_10_1-g | An operand of essentially unsigned type should not be used as the operand to the unary minus operator |
MISRAC2025-RULE_10_1-h | Floating-point expressions shall not be explicitly (syntactically) tested for equality (==) or inequality (!=) |
MISRAC2025-RULE_10_2-a | Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations |
MISRAC2025-RULE_10_3-a | The value of an expression shall not be assigned to an object with a narrower essential type |
MISRAC2025-RULE_10_3-b | The value of an expression shall not be assigned to an object of a different essential type category |
MISRAC2025-RULE_10_4-a | Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category |
MISRAC2025-RULE_10_4-b | The second and third operands of the ternary operator shall have the same essential type category |
MISRAC2025-RULE_10_5-a | The cast operation to essentially enumeration type is not allowed |
MISRAC2025-RULE_10_5-b | Do not cast from or to essentially Boolean type |
MISRAC2025-RULE_10_5-c | Do not use casts between essentially character types and essentially floating types |
MISRAC2025-RULE_10_6-a | The value of a composite expression shall not be assigned to an object with wider essential type |
MISRAC2025-RULE_10_7-a | 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 |
MISRAC2025-RULE_10_7-b | If a composite expression is used as one (second or third) operand of a conditional operator then the other operand shall not have wider essential type |
MISRAC2025-RULE_10_8-a | The value of a composite expression shall not be cast to a different essential type category or a wider essential type |
MISRAC2025-RULE_11_1-a | Conversions shall not be performed between a pointer to a function and any other type than pointer to function |
MISRAC2025-RULE_11_1-b | Conversions shall not be performed between non compatible pointer to a function types |
MISRAC2025-RULE_11_10-a | The '_Atomic' qualifier should not be used with the 'void' type |
MISRAC2025-RULE_11_11-a | Pointers shall not be implicitly compared to NULL |
MISRAC2025-RULE_11_2-a | Conversions shall not be performed between a pointer to an incomplete type and any other type |
MISRAC2025-RULE_11_3-a | A cast shall not be performed between a pointer to object type and a pointer to a different object type |
MISRAC2025-RULE_11_4-b | A conversion should not be performed from an arithmetic type to a pointer type |
MISRAC2025-RULE_11_4-c | A conversion should not be performed from a pointer type to an arithmetic type |
MISRAC2025-RULE_11_5-b | A conversion should not be performed from pointer to void into pointer to object |
MISRAC2025-RULE_11_6-b | A conversion should not be performed from an arithmetic type to a pointer type |
MISRAC2025-RULE_11_6-c | A conversion should not be performed from a pointer type to an arithmetic type |
MISRAC2025-RULE_11_8-a | A conversion shall not remove any 'const', 'volatile' or '_Atomic' qualification from the type accessed via a pointer or by reference |
MISRAC2025-RULE_11_9-a | Literal zero (0) shall not be used as the null-pointer-constant |
MISRAC2025-RULE_11_9-b | Use NULL instead of literal zero (0) as the null-pointer-constant |
MISRAC2025-RULE_12_1-a | Use parentheses to indicate the precedence of operators in expressions |
MISRAC2025-RULE_12_1-c | The operand of the 'sizeof' operator should be enclosed in parentheses |
MISRAC2025-RULE_12_2-a | Avoid incorrect shift operations |
MISRAC2025-RULE_12_2-b | The right-hand operand of a constant expression shift operator shall lie between zero and one less than the width in bits of the essential type of the left-hand operand |
MISRAC2025-RULE_12_3-a | The comma operator shall not be used |
MISRAC2025-RULE_12_4-a | Integer overflow or underflow in constant expression in '+', '-', '*' operator |
MISRAC2025-RULE_12_4-b | Integer overflow or underflow in constant expression in '<<' operator |
MISRAC2025-RULE_12_5-a | The 'sizeof' operator shall not have an operand which is a function parameter declared as "array of type" |
MISRAC2025-RULE_12_6-a | Members of atomic objects of structure and union types should not be directly accessed |
MISRAC2025-RULE_13_1-a | Initializer lists shall not contain persistent side effects |
MISRAC2025-RULE_13_2-a | The value of an expression shall be the same under any order of evaluation that the standard permits |
MISRAC2025-RULE_13_2-b | Avoid code that depends on the order of evaluation of function arguments |
MISRAC2025-RULE_13_2-c | Avoid code that depends on the order of evaluation of the function designator and function arguments |
MISRAC2025-RULE_13_2-d | Avoid code that depends on the order of evaluation of expressions involving a function call |
MISRAC2025-RULE_13_2-e | Between sequence points an object shall have its stored value modified at most once by the evaluation of an expression |
MISRAC2025-RULE_13_2-f | Do not use more than one volatile between two adjacent sequence points |
MISRAC2025-RULE_13_2-g | Avoid code that depends on the order of evaluation of function calls |
MISRAC2025-RULE_13_2-h | The value of an expression with atomic type should be independent from thread interleaving |
MISRAC2025-RULE_13_3-a | A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects |
MISRAC2025-RULE_13_4-a | The result of an assignment operator should not be used |
MISRAC2025-RULE_13_5-a | The right-hand operand of a logical && or || operator shall not contain side effects |
MISRAC2025-RULE_13_6-a | The operand of the sizeof operator shall not contain any expression which has side effects |
MISRAC2025-RULE_13_6-b | Object designated by a volatile lvalue should not be accessed in the operand of the sizeof operator |
MISRAC2025-RULE_13_6-c | The function call shall not be the operand of the sizeof operator |
MISRAC2025-RULE_14_1-a | A loop counter in a 'for' loop shall not have essentially floating type |
MISRAC2025-RULE_14_1-b | A loop counter in 'while' and 'do-while' loops shall not have essentially floating type |
MISRAC2025-RULE_14_2-a | There shall only be one loop counter in a 'for' loop, which shall not be modified in the 'for' loop body |
MISRAC2025-RULE_14_2-b | The first clause of a 'for' loop shall be well-formed |
MISRAC2025-RULE_14_2-c | The second clause of a 'for' loop shall be well-formed |
MISRAC2025-RULE_14_2-d | The third clause of a 'for' statement shall be well-formed |
MISRAC2025-RULE_14_3-ac | Avoid conditions that always evaluate to the same value |
MISRAC2025-RULE_14_4-a | Tests of a value against zero should be made explicit, unless the operand is effectively Boolean |
MISRAC2025-RULE_15_1-a | The goto statement shall not be used |
MISRAC2025-RULE_15_2-a | The goto statement shall jump to a label declared later in the same function body |
MISRAC2025-RULE_15_3-a | Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement |
MISRAC2025-RULE_15_4-a | For any iteration statement there shall be no more than one break or goto statement used for loop termination |
MISRAC2025-RULE_15_5-a | A function shall have a single point of exit at the end of the function |
MISRAC2025-RULE_15_6-a | The statement forming the body of a 'switch', 'while', 'do...while' or 'for' statement shall be a compound statement |
MISRAC2025-RULE_15_6-b | The statement forming the body of an 'if' or 'else' statement should be a compound statement |
MISRAC2025-RULE_15_7-a | All 'if...else-if' constructs shall be terminated with an 'else' clause |
MISRAC2025-RULE_16_1-a | A switch statement shall only contain switch labels and switch clauses, and no other code |
MISRAC2025-RULE_16_1-b | A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement |
MISRAC2025-RULE_16_1-e | Always provide a default branch for switch statements |
MISRAC2025-RULE_16_1-f | A 'default' label shall have a statement or a comment before terminating 'break' |
MISRAC2025-RULE_16_1-g | A 'default' label, if it exists, shall appear as either the first or the last switch label of a switch statement |
MISRAC2025-RULE_16_1-h | Every switch statement shall have at least two switch-clauses |
MISRAC2025-RULE_16_1-i | Every switch branch should be unconditionally terminated |
MISRAC2025-RULE_16_2-a | A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement |
MISRAC2025-RULE_16_3-c | Every switch branch should be unconditionally terminated |
MISRAC2025-RULE_16_4-a | Always provide a default branch for switch statements |
MISRAC2025-RULE_16_4-b | A 'default' label shall have a statement or a comment before terminating 'break' |
MISRAC2025-RULE_16_5-a | A 'default' label, if it exists, shall appear as either the first or the last switch label of a switch statement |
MISRAC2025-RULE_16_6-a | Every switch statement shall have at least two switch-clauses |
MISRAC2025-RULE_16_7-a | A switch expression shall not represent a value that is effectively Boolean |
MISRAC2025-RULE_16_7-b | A switch expression shall not represent a value that is effectively Boolean |
MISRAC2025-RULE_17_1-a | The identifiers va_list, va_arg, va_start, va_end, va_copy should not be used |
MISRAC2025-RULE_17_1-b | The identifiers va_list, va_arg, va_start, va_end should not be used |
MISRAC2025-RULE_17_1-c | The standard header file <stdarg.h> or <cstdarg> shall not be used |
MISRAC2025-RULE_17_10-a | Functions declared as 'noreturn' shall have the 'void' return type |
MISRAC2025-RULE_17_11-a | Declare non-returning functions with the attribute that specifies that they do not return |
MISRAC2025-RULE_17_12-a | A function identifier shall only be used with either a preceding '&', or with a parenthesised parameter list, which may be empty |
MISRAC2025-RULE_17_13-a | Do not include any type qualifiers in the specification of a function type |
MISRAC2025-RULE_17_2-a | Functions shall not call themselves, either directly or indirectly |
MISRAC2025-RULE_17_3-a | Functions shall always have visible prototype at the function call |
MISRAC2025-RULE_17_4-a | All exit paths from a function with non-void return type shall have an explicit return statement with an expression |
MISRAC2025-RULE_17_4-b | All exit paths from a function, except main(), with non-void return type shall have an explicit return statement with an expression |
MISRAC2025-RULE_17_5-a | The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements |
MISRAC2025-RULE_17_7-a | The value returned by a function having non-void return type shall be used |
MISRAC2025-RULE_17_7-b | The value returned by a function having non-void return type shall be used |
MISRAC2025-RULE_17_8-a | A function parameter should not be modified |
MISRAC2025-RULE_17_9-a | Never return from functions that should not return |
MISRAC2025-RULE_18_1-a | Avoid accessing arrays out of bounds |
MISRAC2025-RULE_18_1-b | Avoid accessing arrays and pointers out of bounds |
MISRAC2025-RULE_18_1-c | A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array |
MISRAC2025-RULE_18_10-a | Pointers to variably-modified array types should not be used |
MISRAC2025-RULE_18_2-a | Do not subtract two pointers that do not address elements of the same array |
MISRAC2025-RULE_18_3-a | Do not compare two unrelated pointers |
MISRAC2025-RULE_18_4-a | The +, -, += and -= operators should not be applied to an expression of pointer type |
MISRAC2025-RULE_18_5-a | The declaration of objects should contain no more than 2 levels of pointer indirection |
MISRAC2025-RULE_18_6-a | The address of an object with automatic storage shall not be returned from a function |
MISRAC2025-RULE_18_6-b | The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist |
MISRAC2025-RULE_18_6-c | The address of an object with thread storage duration shall not be assigned to an object with static storage duration |
MISRAC2025-RULE_18_7-a | Flexible array members shall not be declared |
MISRAC2025-RULE_18_8-a | Variable-length arrays should not be used |
MISRAC2025-RULE_18_9-a | Do not modify objects with temporary lifetime |
MISRAC2025-RULE_19_1-a | An object shall not be assigned to an overlapping object |
MISRAC2025-RULE_19_1-b | An object shall not be assigned to an overlapping object |
MISRAC2025-RULE_19_1-c | An object shall not be assigned or copied to an overlapping object |
MISRAC2025-RULE_19_2-a | The union keyword should not be used |
MISRAC2025-RULE_19_3-a | Do not read the value of a non-active union field |
MISRAC2025-RULE_1_1-a | A program should not exceed the translation limits imposed by The Standard (c90) |
MISRAC2025-RULE_1_1-b | A program should not exceed the translation limits imposed by The Standard (c99) |
MISRAC2025-RULE_1_1-c | A program should not exceed the translation limits imposed by The Standard (c90) |
MISRAC2025-RULE_1_1-d | A program should not exceed the translation limits imposed by The Standard (c99) |
MISRAC2025-RULE_1_3-a | Avoid division by zero |
MISRAC2025-RULE_1_3-b | Avoid use before initialization |
MISRAC2025-RULE_1_3-c | Do not use resources that have been freed |
MISRAC2025-RULE_1_3-d | Avoid overflow when reading from a buffer |
MISRAC2025-RULE_1_3-e | Avoid overflow when writing to a buffer |
MISRAC2025-RULE_1_3-f | The value of an expression shall be the same under any order of evaluation that the standard permits |
MISRAC2025-RULE_1_3-g | Avoid code that depends on the order of evaluation of function arguments |
MISRAC2025-RULE_1_3-h | Avoid code that depends on the order of evaluation of the function designator and function arguments |
MISRAC2025-RULE_1_3-i | Avoid code that depends on the order of evaluation of expressions involving a function call |
MISRAC2025-RULE_1_3-j | Between sequence points an object shall have its stored value modified at most once by the evaluation of an expression |
MISRAC2025-RULE_1_3-k | Do not use more than one volatile between two adjacent sequence points |
MISRAC2025-RULE_1_3-l | Avoid code that depends on the order of evaluation of function calls |
MISRAC2025-RULE_1_3-m | The address of an object with automatic storage shall not be returned from a function |
MISRAC2025-RULE_1_3-n | The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist |
MISRAC2025-RULE_1_3-o | The left-hand operand of a right-shift operator shall not have a negative value |
MISRAC2025-RULE_1_4-j | The '_STDC_WANT_LIB_EXT1_' macro should not be defined to the value other than '0' |
MISRAC2025-RULE_1_4-k | The 'rsize_t' type should not be used |
MISRAC2025-RULE_1_4-l | The 'errno_t' type should not be used |
MISRAC2025-RULE_1_4-m | Do not use following macros: RSIZE_MAX, L_tmpnam_s, TMP_MAX_S |
MISRAC2025-RULE_1_4-n | Do not use the functions defined in Annex K of ISO/IEC 9899:2011 standard |
MISRAC2025-RULE_1_5-a | The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage |
MISRAC2025-RULE_1_5-b | Storage type modifiers shall be associated with the type, not the variable or the function |
MISRAC2025-RULE_1_5-c | Function types shall be in prototype form |
MISRAC2025-RULE_1_5-d | Do not use the macro ATOMIC_VAR_INIT |
MISRAC2025-RULE_1_5-e | Do not use the 'bool', 'false' or 'true' identifiers in the #undef directive |
MISRAC2025-RULE_1_5-f | Do not use the ungetc function on a stream with the file position indicator zero |
MISRAC2025-RULE_1_5-g | Do not pass 0 value as a size argument to the realloc function |
MISRAC2025-RULE_20_1-a | #include statements in a file should only be preceded by other preprocessor directives or comments |
MISRAC2025-RULE_20_10-a | The # and ## preprocessor operators should not be used |
MISRAC2025-RULE_20_11-a | A macro parameter immediately following a # operator shall not immediately be followed by a ## operator |
MISRAC2025-RULE_20_12-a | 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 |
MISRAC2025-RULE_20_13-a | Preprocessing directives shall be syntactically meaningful even when excluded by the preprocessor |
MISRAC2025-RULE_20_14-a | All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related |
MISRAC2025-RULE_20_15-a | Do not #define or #undef identifiers with names which start with underscore |
MISRAC2025-RULE_20_15-b | Reserved identifiers, macros and functions in the standard library, shall not be defined, redefined or undefined (C90 code) |
MISRAC2025-RULE_20_15-c | Reserved identifiers, macros and functions in the standard library, shall not be defined, redefined or undefined (C99 code) |
MISRAC2025-RULE_20_15-d | Do not #define nor #undef identifier 'defined' |
MISRAC2025-RULE_20_2-a | The ', ", /* or // characters shall not occur in a header file name |
MISRAC2025-RULE_20_2-b | The \ character should not occur in a header file name |
MISRAC2025-RULE_20_3-a | The #include directive shall be followed by either a <filename> or "filename" sequence |
MISRAC2025-RULE_20_4-a | A macro shall not be defined with the same name as a keyword in C90 |
MISRAC2025-RULE_20_4-b | A macro shall not be defined with the same name as a keyword in C99 |
MISRAC2025-RULE_20_5-a | #undef shall not be used |
MISRAC2025-RULE_20_6-a | Arguments to a function-like macro shall not contain tokens that look like preprocessing directives |
MISRAC2025-RULE_20_7-b | Expressions resulting from the expansion of macro parameters shall be appropriately delimited |
MISRAC2025-RULE_20_8-a | The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1 |
MISRAC2025-RULE_20_9-b | Do not use in preprocessor directives #if and #elif macros not defined in translation unit |
MISRAC2025-RULE_21_10-a | The standard header files <time.h> or <ctime> shall not be used |
MISRAC2025-RULE_21_10-b | The time handling functions and macros of the library <time.h> shall not be used |
MISRAC2025-RULE_21_10-c | The types defined in the library <time.h> shall not be used |
MISRAC2025-RULE_21_11-a | The standard header file <tgmath.h> shall not be used |
MISRAC2025-RULE_21_12-a | The features provided by <fenv.h> should not be used |
MISRAC2025-RULE_21_12-b | The standard header file <fenv.h> shall not be used |
MISRAC2025-RULE_21_13-a | Do not pass incorrect values to ctype.h library functions |
MISRAC2025-RULE_21_14-a | The Standard Library function memcmp shall not be used to compare null terminated strings |
MISRAC2025-RULE_21_15-a | The pointer arguments to the Standard Library functions 'memcmp', 'memmove' and 'memcmp' shall be pointers to qualified or unqualified versions of compatible types |
MISRAC2025-RULE_21_16-a | 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 |
MISRAC2025-RULE_21_17-a | Avoid overflow due to reading a not zero terminated string |
MISRAC2025-RULE_21_17-b | Avoid overflow when writing to a buffer |
MISRAC2025-RULE_21_18-a | The size_t argument passed to any function in string.h shall have an appropriate value |
MISRAC2025-RULE_21_19-a | 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 |
MISRAC2025-RULE_21_19-b | Strings pointed by members of the structure 'lconv' should not be modified |
MISRAC2025-RULE_21_20-a | Pointers returned by certain Standard Library functions should not be used following a subsequent call to the same or related function |
MISRAC2025-RULE_21_21-a | The 'system()' function from the 'stdlib.h' or 'cstdlib' library should not be used |
MISRAC2025-RULE_21_22-a | All arguments to any type-generic macros declared in <tgmath.h> shall have appropriate essential type |
MISRAC2025-RULE_21_23-a | All arguments to any multi-argument type-generic macros declared in <tgmath.h> shall have the same standard type |
MISRAC2025-RULE_21_24-a | The random number generator functions 'rand()' and 'srand()' should not be used |
MISRAC2025-RULE_21_25-a | Only 'memory_order_seq_cst' should be used as an explicit memory order argument |
MISRAC2025-RULE_21_26-a | The Standard Library function mtx_timedlock() shall not be invoked on a mutex that does not support timeout |
MISRAC2025-RULE_21_3-a | Dynamic heap memory allocation shall not be used |
MISRAC2025-RULE_21_4-a | The facilities provided by <setjmp.h> should not be used |
MISRAC2025-RULE_21_4-b | The standard header files <setjmp.h> or <csetjmp> shall not be used |
MISRAC2025-RULE_21_5-a | The standard header files <signal.h> or <csignal> shall not be used |
MISRAC2025-RULE_21_5-b | The signal handling facilities of <signal.h> shall not be used |
MISRAC2025-RULE_21_6-a | The input/output functions from the 'cstdio' and 'cwchar' libraries should not be used |
MISRAC2025-RULE_21_7-a | The 'atof', 'atoi', 'atol' and 'atoll' functions from the 'stdlib.h' or 'cstdlib' library should not be used |
MISRAC2025-RULE_21_8-a | The 'abort()' function from the 'stdlib.h' or 'cstdlib' library shall not be used |
MISRAC2025-RULE_21_8-b | The 'exit()' function from the 'stdlib.h' or 'cstdlib' library shall not be used |
MISRAC2025-RULE_21_8-c | The 'quick_exit()' and '_Exit()' functions from the 'stdlib.h' or 'cstdlib' library shall not be used |
MISRAC2025-RULE_21_8-d | The use of the 'assert' macro should not result in a call to the 'abort' function |
MISRAC2025-RULE_21_9-a | The library functions bsearch and qsort of <stdlib.h> shall not be used |
MISRAC2025-RULE_22_1-a | Ensure resources are freed |
MISRAC2025-RULE_22_10-a | Properly use errno value |
MISRAC2025-RULE_22_11-a | Do not join or detach a thread that was previously joined or detached |
MISRAC2025-RULE_22_12-a | Thread objects, thread synchronization objects, and thread-specific storage pointers shall only be accessed by the appropriate Standard Library functions |
MISRAC2025-RULE_22_13-a | Thread objects, thread synchronization objects and thread-specific storage pointers shall not have automatic storage duration |
MISRAC2025-RULE_22_14-a | A thread synchronization object should not be initialized by a thread |
MISRAC2025-RULE_22_14-b | The second argument passed to the 'mtx_init()' function call should be either 'mtx_plain', 'mtx_timed', 'mtx_plain | mtx_recursive', or 'mtx_timed | mtx_recursive' |
MISRAC2025-RULE_22_15-a | A thread synchronization object should not be destroyed by a thread |
MISRAC2025-RULE_22_16-a | Do not abandon unreleased locks |
MISRAC2025-RULE_22_17-a | Do not release a lock that has not been acquired |
MISRAC2025-RULE_22_18-a | Avoid double locking |
MISRAC2025-RULE_22_19-a | Do not use more than one mutex for concurrent waiting operations on a condition variable |
MISRAC2025-RULE_22_2-a | Do not use resources that have been freed |
MISRAC2025-RULE_22_2-b | Do not free resources using invalid pointers |
MISRAC2025-RULE_22_20-a | A thread-specific storage should not be created by a thread |
MISRAC2025-RULE_22_3-a | The same file shall not be opened for read and write access at the same time on different streams |
MISRAC2025-RULE_22_4-a | Avoid writing to a stream which has been opened as read only |
MISRAC2025-RULE_22_5-a | A pointer to a FILE object shall not be dereferenced |
MISRAC2025-RULE_22_5-b | A pointer to a FILE object shall not be dereferenced by a library function |
MISRAC2025-RULE_22_6-a | Do not use resources that have been freed |
MISRAC2025-RULE_22_7-a | The macro EOF should be compared with the unmodified return value from the Standard Library function |
MISRAC2025-RULE_22_8-a | Properly use errno value |
MISRAC2025-RULE_22_9-a | Properly use errno value |
MISRAC2025-RULE_23_1-a | A generic selection should only be expanded from a macro |
MISRAC2025-RULE_23_1-b | A generic selection used in a macro definition should have a macro parameter in the controlling expression |
MISRAC2025-RULE_23_2-a | A generic selection that is not expanded from a macro shall not contain potential side effects in the controlling expression |
MISRAC2025-RULE_23_3-a | A generic selection shall indicate at least one non-default association |
MISRAC2025-RULE_23_4-a | A generic association shall list an appropriate type |
MISRAC2025-RULE_23_5-a | A generic selection should not depend on implicit pointer type conversion |
MISRAC2025-RULE_23_6-a | The controlling expression of a generic selection shall have an essential type that matches its standard type |
MISRAC2025-RULE_23_6-b | Enumerated types should not be mixed with integer types in generic selections |
MISRAC2025-RULE_23_7-a | A generic selection that is expanded from a macro shall evaluate its argument only once |
MISRAC2025-RULE_23_8-a | The default association shall be placed first or last in the association list |
MISRAC2025-RULE_2_1-a | There shall be no unreachable code in "else" block |
MISRAC2025-RULE_2_1-b | There shall be no unreachable code after 'return', 'break', 'continue', 'goto', 'throw' statements, and after calls to functions with the 'noreturn' attribute |
MISRAC2025-RULE_2_1-c | There shall be no unreachable code in "if/else/while/for" block |
MISRAC2025-RULE_2_1-d | There shall be no unreachable code in switch statement |
MISRAC2025-RULE_2_1-e | There shall be no unreachable code in 'for' loop |
MISRAC2025-RULE_2_1-f | There shall be no unreachable code after 'if' or 'switch' statement |
MISRAC2025-RULE_2_1-g | There shall be no unreachable code after "if" or "switch" statement inside while/for/do...while loop |
MISRAC2025-RULE_2_1-h | Avoid unreachable methods |
MISRAC2025-RULE_2_2-a | All non-null statements shall either have at least one side-effect however executed or cause control flow to change |
MISRAC2025-RULE_2_2-b | Avoid unused values |
MISRAC2025-RULE_2_3-a | A function should not contain unused type declarations |
MISRAC2025-RULE_2_3-b | A source file should not contain unused type declarations |
MISRAC2025-RULE_2_4-a | A function should not contain unused local tag declarations |
MISRAC2025-RULE_2_4-b | A source file should not contain unused tag declarations |
MISRAC2025-RULE_2_5-a | A source file should not contain unused macro definitions |
MISRAC2025-RULE_2_6-a | A function should not contain unused label declarations |
MISRAC2025-RULE_2_7-a | There should be no unused parameters in functions |
MISRAC2025-RULE_2_8-a | A project should not contain unused variables with external linkage |
MISRAC2025-RULE_2_8-b | A project should not contain unused variables with internal linkage |
MISRAC2025-RULE_2_8-c | A project should not contain unused local variables |
MISRAC2025-RULE_3_1-a | The character sequence /* shall not be used within a C-style comment |
MISRAC2025-RULE_3_1-b | The character sequence // shall not be used within a C-style comment |
MISRAC2025-RULE_3_1-c | The character sequence /* shall not be used within a C++-style comment |
MISRAC2025-RULE_3_2-a | Line-splicing shall not be used in // comments |
MISRAC2025-RULE_4_1-a | Octal and hexadecimal escape sequences shall be terminated |
MISRAC2025-RULE_4_2-a | Trigraphs shall not be used |
MISRAC2025-RULE_5_1-a | External identifiers shall be distinct |
MISRAC2025-RULE_5_10-a | The names of standard library macros, objects and functions shall not be reused |
MISRAC2025-RULE_5_10-b | The names of standard library macros, objects and functions shall not be reused (C90) |
MISRAC2025-RULE_5_10-c | The names of standard library macros, objects and functions shall not be reused (C99) |
MISRAC2025-RULE_5_2-a | Identifiers declared in the file scope and in the same name space shall be distinct (c90) |
MISRAC2025-RULE_5_2-b | Identifiers declared in the file scope and in the same name space shall be distinct (c99) |
MISRAC2025-RULE_5_2-c | Identifiers declared in the same block scope and name space shall be distinct (c90) |
MISRAC2025-RULE_5_2-d | Identifiers declared in the same block scope and name space shall be distinct (c99) |
MISRAC2025-RULE_5_3-a | Identifier declared in a local or function prototype scope shall not hide an identifier declared in a global or namespace scope |
MISRAC2025-RULE_5_3-b | Identifiers declared in an inner local scope should not hide identifiers declared in an outer local scope |
MISRAC2025-RULE_5_4-a | The name of a macro should be distinct from the names of its parameters(c90) |
MISRAC2025-RULE_5_4-b | The name of a macro should be distinct from the names of its parameters(c99) |
MISRAC2025-RULE_5_4-c | The name of a macro should be distinct from the names of other macros that are currently defined(c90) |
MISRAC2025-RULE_5_4-d | The name of a macro should be distinct from the names of other macros that are currently defined(c99) |
MISRAC2025-RULE_5_5-a | The names of macros that exist prior to preprocessing should be distinct from the identifiers that exist after preprocessing (c90) |
MISRAC2025-RULE_5_5-b | The names of macros that exist prior to preprocessing should be distinct from the identifiers that exist after preprocessing (c99) |
MISRAC2025-RULE_5_6-a | A typedef name shall be a unique identifier |
MISRAC2025-RULE_5_7-a | A tag name shall be a unique identifier |
MISRAC2025-RULE_5_8-a | Identifiers that define objects with external linkage shall be unique |
MISRAC2025-RULE_5_8-b | Identifiers that define functions with external linkage shall be unique |
MISRAC2025-RULE_5_9-a | Identifiers that define objects with internal linkage shall be unique |
MISRAC2025-RULE_5_9-b | Identifiers that define functions with internal linkage shall be unique |
MISRAC2025-RULE_6_1-a | Bit fields shall only be defined to be of type unsigned int or signed int |
MISRAC2025-RULE_6_2-a | Named bit-fields with signed integer type shall have a length of more than one bit |
MISRAC2025-RULE_6_3-a | A member of a union shall not be declared as a bit-field |
MISRAC2025-RULE_7_1-a | Octal constants (other than zero) shall not be used |
MISRAC2025-RULE_7_2-a | A 'U' suffix shall be applied to all constants of unsigned type |
MISRAC2025-RULE_7_3-a | Use capital 'L' instead of lowercase 'l' to indicate long |
MISRAC2025-RULE_7_4-a | A string literal shall not be modified |
MISRAC2025-RULE_7_5-a | Arguments of integer-constant macros should be decimal, octal, or hexadecimal constants with appropriate values |
MISRAC2025-RULE_7_6-a | The small integer variants of the minimum-width integer constant macros should not be used |
MISRAC2025-RULE_8_1-a | Whenever a function is declared or defined, its type shall be explicitly stated |
MISRAC2025-RULE_8_1-b | Whenever an object is declared or defined, its type shall be explicitly stated |
MISRAC2025-RULE_8_10-a | An inline function shall be declared with the static storage class |
MISRAC2025-RULE_8_11-a | When an array with external linkage is declared, its size should be explicitly specified |
MISRAC2025-RULE_8_12-a | Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique |
MISRAC2025-RULE_8_13-a | 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 |
MISRAC2025-RULE_8_13-b | Declare a type of parameter as typedef to pointer to const if the pointer is not used to modify the addressed object |
MISRAC2025-RULE_8_14-a | The restrict type qualifier shall not be used |
MISRAC2025-RULE_8_15-a | Explicit alignment specifiers in all declarations of an object with external linkage shall be the same |
MISRAC2025-RULE_8_15-b | Explicit alignment specifiers in all declarations of an object with internal linkage shall be the same |
MISRAC2025-RULE_8_16-a | The zero-alignment specifier should not be used in an object declaration |
MISRAC2025-RULE_8_17-a | A declaration of an object should contain at most one explicit alignment specifier |
MISRAC2025-RULE_8_18-a | Tentative definitions should not be placed in a header file |
MISRAC2025-RULE_8_19-a | Objects with external linkage should be declared at file scope |
MISRAC2025-RULE_8_19-b | Functions with external linkage should not be declared in implementation files |
MISRAC2025-RULE_8_19-c | Objects with external linkage should not be declared in implementation files |
MISRAC2025-RULE_8_19-d | Functions should not be declared at block scope |
MISRAC2025-RULE_8_2-a | Identifiers shall be given for all of the parameters in a function prototype declaration |
MISRAC2025-RULE_8_2-b | Function types shall have named parameters |
MISRAC2025-RULE_8_2-c | Function types shall be in prototype form |
MISRAC2025-RULE_8_3-a | If objects or functions are declared more than once their types shall be compatible |
MISRAC2025-RULE_8_3-b | The identifiers used in the declaration and definition of a function shall be identical |
MISRAC2025-RULE_8_3-c | All declarations of an object or function shall have compatible types |
MISRAC2025-RULE_8_4-a | A declaration shall be visible when an object or function with external linkage is defined |
MISRAC2025-RULE_8_4-b | If objects or functions are declared more than once their types shall be compatible |
MISRAC2025-RULE_8_5-a | An external object or function shall not have more than one non-defining declaration in translation unit |
MISRAC2025-RULE_8_6-a | An identifier with external linkage shall have no more then one external definition |
MISRAC2025-RULE_8_6-b | An identifier with external linkage shall have external definition |
MISRAC2025-RULE_8_7-a | Functions and objects should not be defined with external linkage if they are referenced in only one translation unit |
MISRAC2025-RULE_8_8-a | The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage |
MISRAC2025-RULE_8_9-a | Objects shall be defined at block scope if they are only accessed from within a single function |
MISRAC2025-RULE_9_1-a | Avoid use before initialization |
MISRAC2025-RULE_9_2-a | The initializer for an aggregate or union shall be enclosed in braces |
MISRAC2025-RULE_9_3-a | Arrays shall not be partially initialized |
MISRAC2025-RULE_9_4-a | An element of an object shall not be initialized more than once |
MISRAC2025-RULE_9_5-a | Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly |
MISRAC2025-RULE_9_6-a | An initializer using chained designators shall not contain initializers without designators |
MISRAC2025-RULE_9_7-a | Atomic objects shall be properly initialized before being accessed |
MISRACPP2023-7_0_6-b | The argument and the parameter of a function call should have the same type if the parameter is not overload-independent |
MISRACPP2023-7_0_6-c | Passing an argument to a function's ellipsis parameter should not implicitly change the argument's type |
MISRACPP2023-8_2_7-c | A conversion should not be performed from a pointer type to an arithmetic type |
MISRACPP2023-8_2_8-b | A conversion should not be performed from a pointer type to an arithmetic type |
NAMING-58 | A typedef for a standard floating-point type should contain the number indicating its size in its name |
PREPROC-31 | Expressions resulting from the expansion of macro parameters shall be appropriately delimited |