DCL40-C. Incompatible declarations of the same function or object

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 standard [ISO/IEC 9899:1999] 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 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, 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. Furthermore, accessing the object using an lvalue of an incompatible type as done in function f() results in undefined behavior 34 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 */

Noncompliant Code Example (Array Declarations)

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. As before, accessing the object in function f() results in undefined behavior 34 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, 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. Furthermore, invoking the function results in undefined behavior 39 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;
}

Noncompliant Code Example (Excessively Long Identifiers)

In this noncompliant code, 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. In addition, invoking the function leads to undefined behavior 39 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 was taken from GNU Bash version 3.2.

Exceptions

DCL40-EX1: No diagnostic need be issued if a declaration that is incompatible with the definition occurs in a translation unit that does not contain any definition or uses of the function or object other than possibly additional declarations.

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

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

Related Guidelines

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

Bibliography

[Hatton 1995] Section 2.8.3

7.11 Using a value for fsetpos that is returned from fgetpos (FIO44-C)      7 Direct Result      Void 7.13 Do not manipulate time_t typed values directly (MSC05-C)