MISRA C:2023 Rule 1.5

Obsolescent language features shall not be used

Since R2024a

Description

Rule Definition

Obsolescent language features shall not be used¹ .

Rationale

This rule forbids the use of features that are declared obsolescent in the C standard (see, for instance, C11 standard, section 6.11, "Future language directions" and section 7.31, "Future library directions"). These features are declared obsolescent because they have a better alternative specified in the standard, or might exhibit unsafe behavior. These features are also at risk of being withdrawn in a later version of the standard.

Polyspace Implementation

The rule checker checks for use of these obsolescent language features.

Obsolescent Language Feature	Checker Implementation	Language Version
Declaring an identifier with internal linkage at file scope without the static storage class specifier.	The rule checker reports a violation if an identifier is declared multiple times, and some of the declarations have the static storage class specifier while others do not.	C99, C11, C18
Placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration.	The rule checker reports violations on declarations that place a storage class specifier such as static, extern, auto, register or __thread at a position other than the beginning, for instance, after the data type as follows: int static var; //Noncompliant	C99, C11, C18
Use of function declarators with empty parentheses (not prototype-format parameter type declarators).	The rule checker reports a violation if a function declaration uses empty parenthesis () instead of (void) to indicate no parameters.	C99, C11, C18
Use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators).	The rule checker flags K&R style function definitions where the parameter types are separated from the parameter names like this: int foo (x, y) //Noncompliant int x; char y; { }	C99, C11, C18
Use of macro ATOMIC_VAR_INIT (defined in stdatomic.h).	The rule checker reports violations on uses of the macro ATOMIC_VAR_INIT (provided there is a previous inclusion of the header stdatomic.h).	C18
Ability to undefine and perhaps then redefine the macros bool, true, and false (defined in stdbool.h).	The rule checker reports violations on #undef and #define statements that undefine and redefine the macros bool, true, and false (provided there is a previous inclusion of the header stdbool.h).	C99, C11, C18
Use of gets() function (defined in stdio.h).	The rule checker reports violations on use of the gets() function (provided there is a previous inclusion of the header stdio.h).	C99
Use of ungetc() function on a binary stream where the file position indicator is zero.	The rule checker reports violations if the function ungetc() is used on a stream where the file position indicator is zero. For instance: void addToFile() { FILE* my_file = fopen("my_file", "a"); char c; c = getc(my_file); fseek(my_file, 0, SEEK_SET); // File position indicator is 0. ungetc(c, my_file); //Noncompliant }	C99, C11, C18
Use of realloc() function (defined in stdlib.h) with a size argument equal to zero.	The rule checker reports violations on use of the realloc() function with a size argument of zero (provided there is a previous inclusion of the header stdlib.h).	C18

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: Standard C Environment

Category: Required

AGC Category: Required

Version History

Introduced in R2024a