Framework Components 3.31.00.02 Report

October 2014

Introduction

This report summarizes results from two software quality assessment tools used to analyze the software in this product:

• Static Program Analysis: Coverity Static Analysis
• MISRA-C:2004 Rules: Texas Instruments C/C++ Compiler

Unless noted below, all source code, both .c and .h files, for embedded target libraries was analyzed using these tools.

Static Program Analysis Summary

This report summarizes the Static Program Analysis results. For each library, a listing provides:

• the command-line invocation for the tool actually used for the analysis
• summary of lines-of-code (LoC) analyzed and defect types and counts (if any)
• location of defects in the source code (file name and line number) (if any)

Justification for Not Addressing Coverity Violations

• In the ti.sdo.fc.edma3 package, a coverity violation of "OVERRUN_STATIC" is being reported but this seems like a false positive. The complaint is regarding the value "1010u" being assigned to resObj.resId and being used to reference an array. In reality, this value is overwritten by an actual EDMA3 resource Id by the EDMA3_RM_alloc APIs.

---

MISRA-C:2004 Summary

There are several rules in MISRA-C:2004 that are contrary to long-standing coding standards used in this product, and, hence will not be addressed in the product source code. These rules are listed in the table below. The corresponding checks were explicitly disabled in the tool when the source code was analyzed.

MISRA C Id	Brief Summary	Exemption Rationale
5.2/R	Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier.	Coding conventions
5.3/R	A typedef name shall be a unique identifier.	Coding conventions
5.4/R	A tag name shall be a unique identifier.	Coding conventions. The C standard explicitly states (ISO/IEC 9899:1999 6.2.3) that type tags do _not_ need to be unique w.r.t. other identifiers; this pattern is required by our naming/coding conventions so that _all_ types can be consistently identified solely by their letter case.
5.6/A	No identifier in one name space should have the same spelling as an identifier in another name space, with the exception of structure and union member names.	Coding convention
5.7/A	No identifier name should be reused.	Coding convention
6.3/A	typedefs that indicate size and signedness should be used in place of the basic numerical types.	Coding conventions
10.1/R	The value of an expression of integer type shall not be implicitly converted to a different underlying type if (...).	Coding convention
10.3/R	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.	Coding convention
10.6/R	A "U" suffix shall be applied to all constants of unsigned type.	Coding convention
11.3/A	A cast should not be performed between a pointer type and an integral type.	Coding convention
11.4/A	A cast should not be performed between a pointer to object type and a different pointer to object type.	Coding convention
12.6/A	The operands of logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || and !).	Coding convention
12.7/R	Bitwise operators shall not be applied to operands whose underlying type is signed.	Coding convention
14.4/R	The goto statement shall not be used.	Coding convention
14.5/R	The continue statement shall not be used.	Coding convention
15.2/R	An unconditional break statement shall terminate every non-empty switch clause.	Coding convention
15.3/R	The final clause of a switch statement shall be the default clause.	Coding convention
16.7/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.	Coding convention
17.5/A	The declaration of objects should contain no more than 2 levels of pointer indirection.	Coding convention
18.4/R	Unions shall not be used.	Coding convention
19.1/A	#include statements in a file should only be preceded by other preprocessor directives or comments.	Tool reports false positives
19.4/R	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.	Coding convention
19.7/A	A function should not be used in preference to a function-like macro.	Coding conventions
19.13/A	The # and ## preprocessor operators should not be used.	Coding conventions
19.15/R	Precautions shall be taken in order to prevent the contents of a header file being included twice.	Tool reports false positives

Click here to view the MISRA-C:2004 Findings Report.

Justification for Not Addressing MISRA-C:2004 Violations

• In one case, 19.10/R is being reported that complains about macro arguments not being enclosed in parantheses. The macros in this particular instance have arguments that represent elements of a C structure. Enclosing these in parantheses cause C compilation errors and hence this error has been ignored. We are investigating if this requires a cgtools fix.