Page History

Two or more incompatible declarations of the same function or object must not appear in the same program  program because they result in undefined behavior. Subclause The C Standard, 6.2.7 of the C 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:

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.

Anchor
Incompatible Object Declarations Incompatible Object Declarations

Noncompliant Code Example (Incompatible Object Declarations)

In this noncompliant code example, the 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 1514. Furthermore, accessing the object using an lvalue of an incompatible type, as done shown in function f() results in , is undefined behavior 37 with 36 with possible observable results ranging from unintended information exposure to memory overwrite to a hardware trap.

/* In a.c */
extern int i;   /* UB 1514 */

int f(void) {
  return ++i;   /* UB 3736 */
}

/* In b.c */
short i;   /* UB 1514 */

Compliant Solution (Incompatible Object Declarations)

...

/* In a.c */
extern int i;   

int f(void) {
  return ++i;   
}

/* In b.c */
int i;   

Anchor
Incompatible Array Declarations Incompatible Array Declarations

Noncompliant Code Example (Incompatible Array Declarations)

In this noncompliant code example, the variable a is declared to have a pointer type in file a.c but defined to have an array type in file b.c. The two declarations are incompatible, resulting in undefined behavior 1514. As before, accessing the object in function f() results in is undefined behavior 3736 with the typical effect of triggering a hardware trap.

/* In a.c */
extern int *a;   /* UB 1514 */

int f(unsigned int i, int x) {
  int tmp = a[i];   /* UB 3736: read access */
  a[i] = x;         /* UB 3736: write access */
  return tmp;
}

/* In b.c */
int a[] = { 1, 2, 3, 4 };   /* UB 1514 */

Compliant Solution (Incompatible Array Declarations)

...

/* In a.c */
extern int a[];   

int f(unsigned int i, int x) {
  int tmp = a[i];   
  a[i] = x;         
  return tmp;
}

/* In b.c */
int a[] = { 1, 2, 3, 4 };  

Anchor
Incompatible Function Declarations Incompatible Function Declarations

Noncompliant Code Example (Incompatible Function Declarations)

In this noncompliant code example, the function f() is declared in file a.c with one prototype but defined in file b.c with another. The two prototypes are incompatible, resulting in undefined behavior 1514. Furthermore, invoking the function results in is undefined behavior 41 with 37 and typically has catastrophic effectsconsequences.

/* In a.c */
extern int f(int a);   /* UB 1514 */

int g(int a) {
  return f(a);   /* UB 4137 */
}

/* In b.c */
long f(long a) {   /* UB 1514 */
  return a * 2;
}

Compliant Solution (Incompatible Function Declarations)

This compliant solution has compatible declarations of prototypes for the function f():

/* In a.c */
extern int f(int a);   

int g(int a) {
  return f(a);   
}

/* In b.c */
int f(int a) {   
  return a * 2;
}

Noncompliant Code Example (Incompatible Variadic Function Declarations)

In this noncompliant code example, the function buginf() is defined to take a variable number of arguments and expects them all to be signed integers , with a sentinel value of -1:

/* 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 of buginf(), this code it exhibits undefined behavior per subclause in accordance with the C Standard, 6.7.6.3 paragraph 15 7.4, paragraph 14 [ISO/IEC 9899:20112024]:,

For two function types to be compatible, both shall specify compatible return types. ¹⁴⁶) Moreover, the parameter type lists , if both are present, shall agree in the number of parameters and in use of the final 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 promotionsIn the determination of type compatibility and of a composite type, each parameter declared with function or array type is taken as having the adjusted type and each parameter declared with qualified type is taken as having the unqualified version of its declared type.

Compliant Solution (Incompatible Variadic Function Declarations)

...

/* In a.c */
void buginf(const char *fmt, ...) {
   /* ... */
}

/* In b.c */
void buginf(const char *fmt, ...);

Anchor
Excessively Long Identifiers Excessively Long Identifiers

Noncompliant Code Example (Excessively Long Identifiers)

In this noncompliant code example, the length of the identifier declaring the function pointer bash_groupname_completion_function() in the file bashline.h exceeds by 3 the minimum implementation limit of 31 significant initial characters in an external identifier, introducing . This introduces the possibility of colliding with the bash_groupname_completion_funct integer variable defined in file b.c, which is exactly 31 characters long.   On an implementation that exactly meets this limit, this is a violation of  undefined behavior 3130.   This It results in two incompatible declarations of the same function. (see See undefined behavior 1514.) . In addition, invoking the function leads to undefined behavior 4137 with typically catastrophic effects.

/* In bash/bashline.h */
/* UB 14, UB 30 */
extern char * bash_groupname_completion_function(const char *, int); /* UB 15, UB 31 */

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

void f(const char *s, int i) {
  bash_groupname_completion_function(s, i);   /* UB 4137 */
}

/* In b.c */
int bash_groupname_completion_funct;   /* UB 1514, UB 3130 */

NoteNOTE: The identifier bash_groupname_completion_function referenced here was taken from GNU Bash, version 3.2.

Compliant Solution (Excessively Long Identifiers)

In this compliant solution, the length of the identifier declaring the function pointer bash_groupname_completion() in bashline.h is less than 32 characters. Consequently, it cannot clash with bash_groupname_completion_funct on any compliant platform.

/* In bash/bashline.h */
extern char * bash_groupname_completion(const char *, int);   

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

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

/* In b.c */
int bash_groupname_completion_funct; 

Risk Assessment

Automated Detection

Related Guidelines

Related Guidelines

Key here (explains table format and definitions)

Bibliography

...

...

Image Modified Image Modified Image Modified