Page History

Two or more incompatible declarations of the same function or object that appear in the same program shall be diagnosed because they result in undefined behavior.

The C99 C standard [ISO/IEC 9899:19992011] identifies three distinct situations in which undefined behavior (UB) may arise as a result of incompatible declarations of the same function or object:

While the 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.

Noncompliant Code Example (Object Declarations)

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 14 15. Furthermore, accessing the object using an lvalue of an incompatible type as done in function f() results in undefined behavior 34 37 with possible observable results ranging from unintended information exposure to memory overwrite to a hardware trap.

/* in a.c */
extern int i;   /* UB #14 */

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

/* in b.c */
short i;   /* UB #14 */

...

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

/* in a.c */
extern int *a;   /* UB #14 */

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

/* in b.c */
int a[] = { 1, 2, 3, 4 };   /* UB #14 */

Noncompliant Code Example (Function Declarations)

In this noncompliant code example, 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 14 15. Furthermore, invoking the function results in undefined behavior 39 with 41 with typically catastrophic effects.

/* in a.c */
extern int f(int a);   /* UB #14 */

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

/* in b.c */
long f(long a) {   /* UB #14 */
  return a * 2;
}

...

In this noncompliant code example, the length of the identifier declaring the function pointer bash_groupname_completion_function in file bashline.h exceeds by 4 the minimum implementation limit of 31 significant initial characters in an external identifier, introducing the possibility of colliding with the bash_groupname_completion_func integer variable defined in file b.c, which is exactly 31 characters long. On an implementation that exactly meets this limit, the behavior of the program is undefined (see undefined behavior 14 15. In addition, invoking the function leads to undefined behavior 39 behavior 41 with typically catastrophic effects.

/* in bash/bashline.h */
extern char* bash_groupname_completion_function(const char*, int);   /* UB #14 */

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

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

/* in b.c */
int bash_groupname_completion_func;   /* UB #14 */

Note: The identifier bash_groupname_completion_function referenced above here was taken from GNU Bash version 3.2.

...

/* a.c: */
int x = 0; /* the definition */

/* b.c: */
extern char x; /* incompatible declaration */
/* but no other references to 'x' */

...

• ARR31-C. Use consistent array notation across all source files
• ISO/IEC 9899:19992011 Section 6.7.56.2, "Array declarators," and Section 6.2.2, "Linkages of identifiers"

...