Main Content

MISRA C:2023 Dir 1.1

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

Since R2024a

Description

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.

C99 Standard Annex RefBehavior to Be DocumentedHow Polyspace® Helps
J.3.2: EnvironmentAn 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: EnvironmentThe 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 PointThe 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 PointThe 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 PointThe 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 PointThe 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 PointThe 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 PointThe 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 DirectivesThe 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 followpragma. For instance:
#pragma FENV_ACCESS ON

See section 6.10.6 of the C99 Standard.

J.3.12: Library FunctionsWhether 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 FunctionsStrings 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 FunctionsThe 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 FunctionsThe 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 FunctionsThe 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 R2024a

See Also

Topics