Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Two or more incompatible declarations of the same function or object must not appear in the same program  because they result in undefined behavior. Subclause 6.2.7 of the C standard Standard mentions that two types may be distinct yet compatible , and addresses precisely when two distinct types are compatible.

The C Standard identifies four situations in which undefined behavior (UB) may arise as a result of incompatible declarations of the same function or object:

UB

Description

Code

15

Two declarations of the same object or function specify types that are not compatible (6.2.7).

All noncompliant code in this guideline

31—Two identifiers differ only in nonsignificant characters (6.4.2.1).Excessively Long Identifiers

37

An object has its stored value accessed other than by an lvalue of an allowable type (6.5).

Incompatible Object Declarations,
Incompatible Array Declarations

41

A function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function (6.5.2.2).

Incompatible Function Declarations,   Excessively Long Identifiers

Although the effect of two incompatible declarations simply appearing in the same program may be benign on most implementations, the effects of invoking a function through an expression whose type is incompatible with the function definition are typically catastrophic. Similarly, the effects of accessing an object using an lvalue of a type that is incompatible with the object definition may range from unintended information exposure to memory overwrite to a hardware trap.

...

In this noncompliant code example, variable i is declared to have type int in file a.c but defined to be of type short in file b.c. The declarations are incompatible, resulting in undefined behavior undefined behavior 15. Furthermore, accessing the object using an lvalue of an incompatible type, as done in function f(), results in undefined behavior 37 with possible observable results ranging from unintended information exposure to memory overwrite to a hardware trap.

...

Code Block
bgColor#FFCCCC
langc
/* In a.c */
void buginf(const char *fmt, ...) {
   /* ... */
}
 
/* In b.c */
void buginf();

While Although this code appears to be well -defined due to defined because of the prototype-less declaration of buginf(), this code it exhibits undefined behavior per subclause 6.7.6.3 paragraph 15 3, paragraph 15, of the C Standard [ISO/IEC 9899:2011]:

For two function types to be compatible, both shall specify compatible return types.146) Moreover, the parameter type lists, if both are present, shall agree in the number of parameters and in use of the ellipsis terminator; corresponding parameters shall have compatible types. If one type has a parameter type list and the other type is specified by a function declarator that is not part of a function definition and that contains an empty identifier list, the parameter list shall not have an ellipsis terminator and the type of each parameter shall be compatible with the type that results from the application of the default argument promotions.

...

...

Code Block
bgColor#ccccff
langc
/* In bash/bashline.h */
extern char* bash_groupname_completion(const char*, int);   

/* In a.c */
#include <bashline.h>

void f(const char *s, int i) {
  bash_groupname_completion(s, i);  
}

/* In b.c */
int bash_groupname_completion_funct; 

...

Risk Assessment

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

DCL40-C

Low

Unlikely

Medium

P2

L3

...

[Hatton 1995]Section 2.8.3
[ISO/IEC 9899:2011]Subclause 6.7.6.3, "Function Declarators (including Prototypes)"
Subclause J.2, "Undefined behaviorBehavior"

 

...