MISRA C:2012 Dir 1.1

Any implementation-defined behavior on which the output of the program depends shall be documented and understood

Description

Note

Using Code Prover for checking coding rules is no longer supported. See Version History.

Directive Definition

Any implementation-defined behavior on which the output of the program depends shall be documented and understood.

Rationale

A code construct has implementation-defined behavior if the C standard allows compilers to choose their own specifications for the construct. The full list of implementation-defined behavior is available in Annex J.3 of the standard ISO/IEC 9899:1999 (C99) and in Annex G.3 of the standard ISO/IEC 9899:1990 (C90).

If you understand and document all implementation-defined behavior, you can be assured that all output of your program is intentional and not produced by chance.

Polyspace Implementation

The analysis detects the following possibilities of implementation-defined behavior in C99 and their counterparts in C90. If you know the behavior of your compiler implementation, justify the analysis result with appropriate comments. To justify a result, assign one of these statuses: Justified, No action planned, or Not a defect.

Tip

To mass-justify all results that indicate the same implementation-defined behavior, use the Detail column on the Results List pane. Click the column header so that all results with the same entry are grouped together. Select the first result and then select the last result while holding the Shift key. Assign a status to one of the results. If you do not see the Detail column, right-click any other column header and enable this column.

In accordance with MISRA C:2012 Addendum 1, several MISRA C:2004 rules are mapped to MISRA C:2012 Dir 1.1 as required rules, including:

Rule 12.12 — The underlying bit representations of floating-point values shall not be used.
Rule 13.3 — Floating-point expressions shall not be tested for equality or inequality.
Rule 20.5 — The error indicator errno shall not be used.

C99 Standard Annex Ref	Behavior to Be Documented	How Polyspace^® Helps
J.3.2: Environment	An alternative manner in which `main` function may be defined.	The analysis flags `main` with arguments and return types other than: int main(void) { ... } or int main(int argc, char *argv[]) { ... } See section 5.1.2.2.1 of the C99 Standard.
J.3.2: Environment	The set of environment names and the method for altering the environment list used by the `getenv` function.	The analysis flags uses of the `getenv` function. For this function, you need to know the list of environment variables and how the list is modified. See section 7.20.4.5 of the C99 Standard.
J.3.6: Floating Point	The rounding behaviors characterized by non-standard values of `FLT_ROUNDS`.	The analysis flags the include of `float.h` if values of `FLT_ROUNDS` are outside the set, {-1, 0, 1, 2, 3}. Only the values in this set lead to well-defined rounding behavior. See section 5.2.4.2.2 of the C99 Standard.
J.3.6: Floating Point	The evaluation methods characterized by non-standard negative values of `FLT_EVAL_METHOD`.	The analysis flags the include of `float.h` if values of `FLT_EVAL_METHOD` are outside the set, {-1, 0, 1, 2}. Only the values in this set lead to well-defined behavior for floating-point operations. See section 5.2.4.2.2 of the C99 Standard.
J.3.6: Floating Point	The direction of rounding when an integer is converted to a floating-point number that cannot exactly represent the original value.	The analysis flags conversions from integer to floating-point data types of smaller size (for example, 64-bit `int` to 32-bit `float`). See section 6.3.1.4 of the C99 Standard.
J.3.6: Floating Point	The direction of rounding when a floating-point number is converted to a narrower floating-point number.	The analysis flags these conversions: `double` to `float` `long double` to `double` or `float` See section 6.3.1.5 of the C99 Standard.
J.3.6: Floating Point	The default state for the `FENV_ACCESS` pragma.	The analysis flags use of the pragma other than: #pragma STDC FENV_ACCESS ON or #pragma STDC FENV_ACCESS OFF See section 7.6.1 of the C99 Standard.
J.3.6: Floating Point	The default state for the `FP_CONTRACT` pragma.	The analysis flags use of the pragma other than: #pragma STDC FP_CONTRACT ON or #pragma STDC FP_CONTRACT OFF See section 7.12.2 of the C99 Standard.
J.3.11: Preprocessing Directives	The behavior on each recognized non-STDC #pragma directive.	The analysis flags the pragma usage: #pragma pp-tokens where the processing token `STDC` does not immediately follow`pragma`. For instance: #pragma FENV_ACCESS ON See section 6.10.6 of the C99 Standard.
J.3.12: Library Functions	Whether the `feraiseexcept` function raises the ‘‘inexact’’ floating-point exception in addition to the ‘‘overflow’’ or ‘‘underflow’’ floating-point exception.	The analysis flags calls to the `feraiseexcept` function. See section 7.6.2.3 of the C99 Standard.
J.3.12: Library Functions	Strings other than `"C"` and `""` that may be passed as the second argument to the `setlocale` function.	The analysis flags calls to the `setlocale` function when its second argument is not `"C"` or `""`. See section 7.11.1.1 of the C99 Standard.
J.3.12: Library Functions	The types defined for `float_t` and `double_t` when the value of the `FLT_EVAL_METHOD` macro is less than 0 or greater than 2.	The analysis flags the include of `math.h` if `FLT_EVAL_METHOD` has values outside the set {0,1,2}. See section 7.12 of the C99 Standard.
J.3.12: Library Functions	The base-2 logarithm of the modulus used by the`remquo` functions in reducing the quotient.	The analysis flags calls to the `remquo`, `remquof` and `remquol` function. See section 7.12.10.3 of the C99 Standard.
J.3.12: Library Functions	The termination status returned to the host environment by the `abort`, `exit`, or `_Exit` function.	The analysis flags calls to the `abort`, `exit`, or `_Exit` function. See sections 7.20.4.1, 7.20.4.3 or 7.20.4.4 of the C99 Standard.

Troubleshooting

If you expect a rule violation but do not see it, refer to Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Check Information

Group: The implementation

Category: Required

AGC Category: Required

Version History

Introduced in R2017b

expand all

R2024a: Using Code Prover to check for coding rule violations is no longer supported

Checking for coding rule violations and computing code metrics by using Code Prover is no longer supported. To check for coding rule violations and to compute code metrics, use Bug Finder. See Migrate Code Prover Workflows for Checking Coding Standards and Code Metrics to Bug Finder.

R2024a: Floating-point test for equality with type casting

The rule checker reports a violation when a floating-point number is used in a test for equality or inequality after a type conversion occurs.

    extern double exampleA;

     if ((exampleA <= 0.0F) && (exampleA >= 0.0F)) {  // Noncompliant
    }

R2022a: Using Code Prover to check for coding rule violations is not recommended

Checking for coding rule violations and computing code metrics by using Code Prover is not recommended. This workflow will be removed in a future release. To check for coding rule violations and to compute code metrics, use Bug Finder. See Migrate Code Prover Workflows for Checking Coding Standards and Code Metrics to Bug Finder. To see how Bug Finder checks this directive, see MISRA C:2012 Dir 1.1.