You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

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 C Standard [ISO/IEC 9899:2011] identifies three distinct 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.

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.

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

/* in a.c */
extern int i;   /* UB 15 */

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

/* in b.c */
short i;   /* UB 15 */

Compliant Solution

This compliant solution has compatible declarations of the variable i:

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

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

/* in b.c */
int i;   

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 15. As before, accessing the object in function f() results in undefined behavior 37 with the typical effect of triggering a hardware trap.

/* in a.c */
extern int *a;   /* UB 15 */

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

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

Compliant Solution

This compliant solution declares a as an array in a.c and b.c:

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

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

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

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 15. Furthermore, invoking the function results in undefined behavior 41 with typically catastrophic effects.

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

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

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

Compliant Solution

This compliant solution has compatible declarations of 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 (Excessively Long Identifiers)

In this noncompliant code example, the length of the identifier declaring the function pointer bash_groupname_completion_function() in file bashline.h exceeds by 3 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 30 characters long. On an implementation that exactly meets this limit, the behavior of the program is undefined (see undefined behavior 15). In addition, invoking the function leads to undefined behavior 41 with typically catastrophic effects.

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

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

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

/* in b.c */
int bash_groupname_completion_func;   /* UB 15 */

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

Compliant Solution

In this compliant solution, the length of the identifier declaring the function pointer bash_groupname_completion() in bashline.h is less than 32 characters:

/* 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_func; 

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

CERT C Secure Coding StandardARR31-C. Use consistent array notation across all source files
ISO/IEC TS 17961 (Draft)Declaring the same function or object in incompatible ways [funcdecl]

Bibliography

[Hatton 1995]Section 2.8.3

 


  • No labels