Main Content

CERT C Compliance Summary Tables

MathWorks® evaluates C code generated by Embedded Coder® from Simulink® models and Stateflow® charts against the CERT® C coding standards1 . The evaluation results are available in these summary tables.

The tables show the compliance status of generated code with CERT C rules:

  • Compliant: The generated code is fully compliant with the CERT C coding standards if you follow the modeling recommendations associated with the rule.

  • Noncompliant: The generated code fails to satisfy the CERT C coding standards.

Note

For rules marked as Noncompliant*, you can generate CERT C compliant code in some modeling instances by following the modeling guidelines shown in the table, where applicable.

The table also provides guidance on achieving compliance, where applicable:

  • Model Advisor checks, which facilitates the model assessment process to achieve code compliance.

  • Modeling recommendations, which describe model settings, blocks usage, and block parameter settings that improve code compliance.

  • Explanatory notes describe violations that are not within the scope of Embedded Coder, and other limitations.

When preparing the CERT C compliance statement for your project, you can use the tables in the CERT C Code Compliance Evaluation Summary. The tables align with the published CERT C Rules and Recommendations (Polyspace Bug Finder). The tables are based only on Rules as described in Section 1.7 of the SEI CERT C Coding Standards, 2016 edition. Recommendations are not considered.

Note

To detect issues in a model that might produce CERT C coding standard violations, use the Model Advisor to run the Model Advisor Checks for CERT C, SWE, and ISO/IEC TS 17961 Coding Standards (Simulink Check).

CERT C Code Compliance Evaluation Summary

Rule 01. Preprocessor (PRE)

RuleDescriptionaCompliance
PRE30-CDo not create a universal character name through concatenation.

Compliant

PRE31-CAvoid side effects in arguments to unsafe macros.Compliant
PRE32-CDo not use preprocessor directives in invocations of function-like macros.Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 02. Declarations and Initialization (DCL)

RuleDescriptionaCompliance
DCL30-CDeclare objects with appropriate storage durations.Compliant
DCL31-CDeclare identifiers before using them.

Compliant

DCL36-CDo not declare an identifier with conflicting linkage classifications.Compliant
DCL37-CDo not declare or define a reserved identifier.

Noncompliant*

DCL38-CUse the correct syntax when declaring a flexible array member.

Compliant

DCL39-CAvoid information leakage when passing a structure across a trust boundary.Noncompliant
DCL40-C Do not create incompatible declarations of the same function or object.Compliant
DCL41-C Do not declare variables inside a switch statement before the first case label.Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 03. Expressions (EXP)

RuleDescriptionaCompliance
EXP30-CDo not depend on the order of evaluation for side effects.

Compliant

EXP32-CDo not access a volatile object through a nonvolatile reference.

Compliant

EXP33-CDo not read uninitialized memory.

Compliant

EXP34-CDo not dereference null pointers.

Compliant

EXP35-CDo not modify objects with temporary lifetime.

Compliant

EXP36-CDo not cast pointers into more strictly aligned pointer types.

Noncompliant*

EXP37-CCall functions with the correct number and type of arguments.

Compliant

EXP39-CDo not access a variable through a pointer of an incompatible type.

Noncompliant*

EXP40-CDo not modify constant objects.

Compliant

EXP42-CDo not compare padding data.

Compliant

EXP43-CAvoid undefined behavior when using restrict-qualified pointers.

Noncompliant*

EXP44-CDo not rely on side effects in operands to sizeof, _Alignof, or _Generic.Compliant
EXP45-CDo not perform assignments in selection statements.

Compliant

EXP46-CDo not use a bitwise operator with a Boolean-like operand.

Noncompliant

EXP47-CDo not call va_arg with an argument of the incorrect type.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 04. Integers (INT)

RuleDescriptionaCompliance
INT30-CEnsure that unsigned integer operations do not wrap.

Noncompliant*

INT31-CEnsure that integer conversions do not result in lost or misinterpreted data.

Noncompliant*

INT32-CEnsure that operations on signed integers do not result in overflow.

Compliant

INT33-CEnsure that division and remainder operations do not result in divide-by-zero errors.

Compliant

INT34-CDo not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand.

Compliant

INT35-CUse correct integer precisions.Compliant
INT36-CConverting a pointer to integer or integer to pointer.Noncompliant

a Copyright © 2016 Carnegie Mellon University.

Rule 05. Floating Point (FLP)

RuleDescriptionaCompliance
FLP30-CDo not use floating-point variables as loop counters.

Noncompliant*

FLP32-CPrevent or detect domain and range errors in math functions.

Compliant

FLP34-CEnsure that floating-point conversions are within range of the new type.

Compliant

FLP36-CPreserve precision when converting integral values to floating-point type.

Compliant

FLP37-CDo not use object representations to compare floating-point values.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 06. Arrays (ARR)

RuleDescriptionaCompliance
ARR30-CDo not form or use out-of-bounds pointers or array subscripts.

Noncompliant*

ARR32-CEnsure size arguments for variable length arrays are in a valid range.

Compliant

ARR36-CDo not subtract or compare two pointers that do not refer to the same array.

Compliant

ARR37-CDo not add or subtract an integer to a pointer to a nonarray object.

Compliant

ARR38-CGuarantee that library functions do not form invalid pointers.

Compliant

ARR39-CDo not add or subtract a scaled integer to a pointer.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 07. Characters and Strings (STR)

RuleDescriptionaCompliance
STR30-CDo not attempt to modify string literals.

Compliant

STR31-CGuarantee that storage for strings has sufficient space for character data and the null terminator.

Compliant

STR32-CDo not pass a non-null-terminated character sequence to a library function that expects a string.

Compliant

STR34-CCast characters to unsigned char before converting to larger integer sizes.

Noncompliant*

STR37-CArguments to character-handling functions must be representable as an unsigned char.

Compliant

STR38-CDo not confuse narrow and wide character strings and functions.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 08. Memory Management (MEM)

RuleDescriptionaCompliance
MEM30-CDo not access freed memory.

Compliant

MEM31-CFree dynamically allocated memory when no longer needed.

Compliant

MEM33-CAllocate and copy structures containing a flexible array member dynamically.

Compliant

MEM34-COnly free memory allocated dynamically.

Compliant

MEM35-CAllocate sufficient memory for an object.

Compliant

MEM36-CDo not modify the alignment of objects by calling realloc().

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 09. Input Output (FIO)

RuleDescriptionaCompliance
FIO30-CExclude user input from format strings.

Compliant

FIO32-CDo not perform operations on devices that are only appropriate for files.

Noncompliant*

FIO34-C Distinguish between characters read from a file and EOF or WEOF.

Compliant

FIO37-CDo not assume that fgets() or fgetws() returns a nonempty string when successful.

Compliant

FIO38-CDo not copy a FILE object.

Compliant

FIO39-C Do not alternately input and output from a stream without an intervening flush or positioning call.

Compliant

FIO40-CReset strings on fgets() or fgetws() failure.

Compliant

FIO41-CDo not call getc(), putc(), getwc(), or putwc() with a stream argument that has side effects.

Compliant

FIO42-CClose files when they are no longer needed.

Compliant

FIO44-COnly use values for fsetpos() that are returned from fgetpos().

Compliant

FIO45-CAvoid TOCTOU race conditions while accessing files.

Compliant

FIO46-CDo not access a closed file.

Compliant

FIO47-CUse valid format strings.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 10. Environment (ENV)

RuleDescriptionaCompliance
ENV30-CDo not modify the object referenced by the return value of certain functions.

Compliant

ENV31-CDo not rely on an environment pointer following an operation that may invalidate it.

Compliant

ENV32-CAll exit handlers must return normally.

Compliant

ENV33-CDo not call system().

Compliant

ENV34-CDo not store pointers returned by certain functions.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 11. Signals (SIG)

RuleDescriptionaCompliance
SIG30-CCall only asynchronous-safe functions within signal handlers.

Compliant

SIG31-CDo not access shared objects in signal handlers.

Compliant

SIG34-CDo not call signal() from within interruptible signal handlers.

Compliant

SIG35-C Do not return from a computational exception signal handler.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 12. Error Handling (ERR)

RuleDescriptionaCompliance
ERR30-CSet errno to zero before calling a library function known to set errno, and check errno only after the function returns a value indicating failure.

Compliant

ERR32-CDo not rely on indeterminate values of errno.

Compliant

ERR33-CDetect and handle standard library errors.

Compliant

ERR34-CDetect errors when converting a string to a number.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 14. Concurrency (CON)

RuleDescriptionaCompliance
CON30-CClean up thread-specific storage.

Compliant

CON31-C Do not destroy a mutex while it is locked.

Compliant

CON32-C Prevent data races when accessing bit-fields from multiple threads.

Compliant

CON33-CAvoid race conditions when using library functions.

Compliant

CON34-CDeclare objects shared between threads with appropriate storage durations.

Compliant

CON35-CAvoid deadlock by locking in a predefined order.

Compliant

CON36-CWrap functions that can spuriously wake up in a loop.

Compliant

CON37-CDo not call signal() in a multithreaded program.

Compliant

CON38-CPreserve thread safety and liveness when using condition variables.

Compliant

CON39-C Do not join or detach a thread that was previously joined or detached.

Compliant

CON40-C Do not refer to an atomic variable twice in an expression.

Compliant

CON41-CWrap functions that can fail spuriously in a loop.

Compliant

CON43-CDo not allow data races in multithreaded code.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 48. Miscellaneous (MSC)

RuleDescriptionaCompliance
MSC30-CDo not use the rand() function for generating pseudorandom numbers.

Noncompliant

MSC32-CProperly seed pseudorandom number generators.

Noncompliant

MSC33-CDo not pass invalid data to the asctime() function.

Compliant

MSC37-CEnsure that control never reaches the end of a non-void function.

Compliant

MSC38-CDo not treat a predefined identifier as an object if it might only be implemented as a macro.

Compliant

MSC39-CDo not call va_arg() on a va_list that has an indeterminate value.

Compliant

MSC40-CDo not violate constraints.

Compliant

MSC41-CNever hard code sensitive information.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Rule 50. POSIX (POS)

RuleDescriptionaCompliance
POS30-CUse the readlink() function properly.

Compliant

POS34-CDo not call putenv() with a pointer to an automatic variable as the argument.

Compliant

POS35-CAvoid race conditions while checking for the existence of a symbolic link.

Compliant

POS36-CObserve correct revocation order while relinquishing privileges.

Compliant

POS37-CEnsure that privilege relinquishment is successful.

Compliant

POS38-CBeware of race conditions when using fork and file descriptors.

Compliant

POS39-CUse the correct byte ordering when transferring data between systems.

Compliant

POS44-CDo not use signals to terminate threads.

Compliant

POS47-CDo not use threads that can be canceled asynchronously.

Noncompliant

POS48-CDo not unlock or destroy another POSIX thread's mutex.

Compliant

POS49-CWhen data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed.

Compliant

POS50-CDeclare objects shared between POSIX threads with appropriate storage durations.

Compliant

POS51-CAvoid deadlock with POSIX threads by locking in predefined order.

Compliant

POS52-CDo not perform operations that can block while holding a POSIX lock.

Compliant

POS53-CDo not use more than one mutex for concurrent waiting operations on a condition variable.

Compliant

POS54-CDetect and handle POSIX library errors.

Noncompliant

a Copyright © 2016 Carnegie Mellon University.

Rule 51. Microsoft Windows (WIN)

RuleDescriptionaCompliance
WIN30-CProperly pair allocation and deallocation functions.

Compliant

a Copyright © 2016 Carnegie Mellon University.

Explanatory Notes

Usage of const or volatile qualifiers

The code generator produces noncompliant code for Simulink data objects with its storage class configured with const or volatile qualifiers.

Usage of Hardware board configuration

Simulink models configured for support packages like Simulink Support Package for Raspberry Pi® Hardware, C2000™ Microcontroller Blockset, or such configurations may generate noncompliant code.

Note

Third-party files such as drivers used with code that is generated using Embedded Coder are not considered in the evaluation.

Blocks usage

Rate Transition block and Matrix Interpolation block generate noncompliant code.

Flexible array violation

Polyspace® may report violations if the generated code has a structure with one-dimensional array. For example, this code uses a structure DW_mg_foreach_T and a member array CoreSubsys. 

typedef struct {
  real_T Delay_DSTATE[2];              /* '<Root>/Delay' */
  ...
  DW_CoreSubsys_mg_foreach_T CoreSubsys[1];/* '<Root>/S1' */
} DW_mg_foreach_T;

DW_mg_foreach_T mg_foreach_DW;
mg_foreach_DW.CoreSubsys[0].Delay_DSTATE[0] = 0.0;

CoreSubsys is a fixed size array and not a flexible array. In this case, the flexible array violation coming from the Polyspace is not an issue.

Configuration of Variant choices

Variant Source block not configured with the default variant choice generates an empty else statement. To avoid this, specify a default variant control variable for the variant blocks. For more information, see Types of Variant Controls in expression Mode.

Usage of Model Configuration Parameter 'Classic call interface'

When the model configuration parameter Classic call interface is enabled, Polyspace may report a null pointer dereferencing violation in the generated code. For example, this code uses a static variable exmpModelK_m and is dereferenced by a variable mdlTsMap.

static RT_MODEL__EXAMPMODEL exmpModelK_m;
RT_MODEL__EXMPMODEL *const exmpModelK_m = &exmpModelK_m_;

.....

  /* Initialize timing info */
  {
    int_T *mdlTsMap = exmpModelK_m->Timing.sampleTimeTaskIDArray;
    mdlTsMap[0] = 0;

    exmpModelK_m->Timing.sampleTimeTaskIDPtr = (&mdlTsMap[0]); 

... 

}
In this case of violation, it is the static memory which is dereferenced. Static memory address is of non-NULL in nature and the violation coming from the Polyspace is not an issue.

The Classic call interface parameter will be removed in a future release. To use the call interface that is common to GRT- and ERT-based system target files, clear this parameter, which is the default setting. (since R2012a) For information on updating a model configuration or migrating a custom GRT-based system target file to use the unified call interface, see Version History on the Classic call interface reference page.

Usage of Model Configuration Parameter 'Leverage target hardware instruction set extensions'

When the model configuration parameter Leverage target hardware instruction set extensions is set to anything other than None, the generated SIMD instruction starts with the identifier _mm. Generation of these intrinsic functions is not supported by Embedded Coder. For more information, see Generate SIMD Code from Simulink Blocks for Intel Platforms.

Identifier specification

You can configure Embedded Coder to limit the number of characters imposed by the implementation. For more information, see Maximum identifier length.

To ensure unique names for different types of variables (such as local variables, global variables, and macros), implement a naming convention. For more information, see Model Configuration Parameters: Code Generation Symbols.

In case of long identifiers, use shared utilities. For more information, see Generate Shared Utility Code.

If you specify identifier naming rules, you are responsible for ensuring compliance.

Run-time error analysis

Use Simulink Design Verifier™ to detect design errors at the model level. For more information, see Analyze Models for Design Errors (Simulink Design Verifier).

To handle overflow violations, see Handle Overflows in Simulink Models (Fixed-Point Designer).

Use Polyspace Bug Finder™ to identify run-time errors and Polyspace Code Prover™ to prove the absence of run-time errors. For more information, see Run Polyspace Analysis on Code Generated with Embedded Coder (Polyspace Code Prover):

Usage of User-Written code

User-written C code and third-party libraries that are used with code generated by Embedded Coder are not considered in the evaluation.

See Also

1 Polyspace is used to assess the generated code from Embedded Coder against the CERT C coding guidelines. Other CERT C code analysis tools can yield different results. The evaluation does not include user-defined functions.