Deviations Rationale for MISRA C Compliance

Instances in which the generated code does not comply with the MISRA C:2012 guidelines are marked as deviations in the MISRA C:2012 Compliance Summary Tables. In accordance with Section 5.4 of the MISRA C:2012 guidelines,information about the deviations includes:

The guideline being deviated
The circumstances in which the deviation is permitted
Justification for the deviation, including a risk assessment
Demonstration of how safety is assured
Potential consequences of non-conformance

Deviations to the MISRA C:2012 directives and rules include:

MISRA C:2012 Directive 4.7 Deviation Rationale

Directive Definition

If a function returns error information, then that error information shall be tested.

Rationale

Note

This directive is violated only when an AUTOSAR-based code generation target is used.

When a function call provides information that indicates an unsuccessful operation, the calling program has to check for the indication of an error when the function is returned. The function calls are not limited to calls in the standard library.

Description

AUTOSAR sender interface function calls, such as Rte_Write_..., have return type Std_ReturnType that indicates if writing the value was successful. The matching Simulink pattern is a top-level output port that is configured as an AUTOSAR Sender Interface.

Model Example

AUTOSAR Configuration

Generated Code Sample

In the sample code, note the use of AUTOSAR function call Rte_Write_... in Rte_Write_OUT_DE1_OUT_DE1(rtb_TmpSignalConversionAtIN_DE1);.

void Runnable_Step(void)
{
  /* local block i/o variables */
  real_T rtb_TmpSignalConversionAtIN_DE1;
  …
  rtb_TmpSignalConversionAtIN_D_l = Rte_Read_IN_DE1_IN_DE1
    (&rtb_TmpSignalConversionAtIN_DE1);
  …
  if (rtb_TmpSignalConversionAtIN_D_l > 0) {
    …
    Rte_Write_OUT_DE1_OUT_DE1(rtb_TmpSignalConversionAtIN_DE1);
  }
  …
}

Justification

Failures of Rte_Write_... function calls are typically handled on the receiver side because function call returns do not always include all potential errors.

Conditions Under Which the Deviation is Requested

The deviation is requested for all instances of AUTOSAR sender ports.

Consequences of Noncompliance

The calling program cannot react when the sender operation is unsuccessful.

Actions to Control Reporting

When a Polyspace^® analysis of your code finds known or acceptable coding rule violations, you can suppress the violations in subsequent analyses by adding code annotations (Polyspace Bug Finder) to the Outport block. In future analyses, Polyspace hides results justified through annotations in the Results List pane. To review the coding rule violations, see Filter and Group Results in Polyspace Desktop User Interface (Polyspace Bug Finder).

If you have already provided annotations for MISRA C:2004 violations, Polyspace imports these justifications when you check your code for MISRA C:2012 violations. For additional information, see Import Justifications from Older Standard to Newer Standard (Polyspace Bug Finder).

For additional information, see:

MISRA C:2012 Rule 13.5 Deviation Rationale

Rule Definition

The right hand operand of a logical && or || operator shall not contain persistent side effects.

Rationale

Persistent side effects of the right hand side operand of the && and || operators can occur depending on the left hand side operand, which is contrary to the expectations of the programmer.

Note

The term persistent side effect is defined in "Appendix J: Glossary" of the MISRA C:2012 Guidelines for the Use of C Language in Critical Systems document.

Description

Using math operations as second input to Logical Operator blocks configured as AND or OR operation.

Model Example

Generated Code Sample

In the sample code, note the use of operand && in Y1 = (U1 && (sqrt(U2) <= 3.0));.

/* Exported block signals */
boolean_T U1;                /* '<Root>/U1' */
real_T U2;                   /* '<Root>/U2' */
boolean_T Y1;                /* '<Root>/Logical Operator' */

/* Model step function */
void DEV_R1305_01main_step(void)
{
  /* Logic: '<Root>/Logical Operator' incorporates:
   *  Constant: '<S1>/Constant'
   *  Inport: '<Root>/U1'
   *  Inport: '<Root>/U2'
   *  RelationalOperator: '<S1>/Compare'
   *  Sqrt: '<Root>/Sqrt'
   */
  Y1 = (U1 && (sqrt(U2) <= 3.0));
}

Justification

Some standard math functions have at least one persistent side effect of modifying the global errno variable, as defined in the C90 or C99 standard. Since the errno variable is not used by Embedded Coder^®, the second operand can be treated as not having persistent side effects.

Note

Polyspace Bug Finder™ treats every function with no available source code as potentially having side effects.

Conditions Under Which the Deviation is Requested

This deviation is requested for all calls to standard math functions used as right hand side argument of && and || operators.

Consequences of Noncompliance

There are no consequences associated with noncompliance with MISRA C:2012 Rule 13.5 in the circumstances described in this deviation record. There are no additional verification and validation requirements resulting from this deviation.

Actions to Control Reporting

When a Polyspace analysis of your code finds known or acceptable coding rule violations, you can suppress the violations in subsequent analyses by adding code annotations (Polyspace Bug Finder) to the Logical Operator block. In future analyses, Polyspace hides results justified through annotations in the Results List pane. To review the coding rule violations, see Filter and Group Results in Polyspace Desktop User Interface (Polyspace Bug Finder).

For additional information, see MISRA C:2012 Compliance Summary Tables.