Two or more incompatible declarations of the same function or object that must not appear in the same program shall be diagnosed because they result in undefined behavior. The C Standard, 6.2.7, mentions that two types may be distinct yet compatible and addresses precisely when two distinct types are compatible.
The C Standard [ISO/IEC 9899:2011] identifies three distinct 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 |
---|---|---|
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 |
An object has its stored value accessed other than by an lvalue of an allowable type (6.5). |
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). |
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 | ||||
---|---|---|---|---|
|
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 15. Furthermore, accessing the object using an lvalue of an incompatible type, as done shown in function f()
results in , is undefined behavior 37 with possible observable results ranging from unintended information exposure to memory overwrite to a hardware trap.
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn a.c */ extern int i; /* UB 15 */ int f(void) { return ++i; /* UB 37 */ } /* inIn b.c */ short i; /* UB 15 */ |
Compliant Solution (Incompatible Object Declarations)
This compliant solution has compatible declarations of the variable i
. :
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn a.c */ extern int i; int f(void) { return ++i; } /* inIn b.c */ int i; |
Anchor | ||||
---|---|---|---|---|
|
In this noncompliant code example, the variable a
is declared to have array a pointer type in file a.c
but defined to have pointer an array 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 is undefined behavior 37 with the typical effect of triggering a hardware trap.
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn a.c */ extern int *a; /* UB 15 */ int f(unsigned int i, int x) { int tmp = a[i]; /* UB 37: read access */ a[i] = x; /* UB 37: write access */ return tmp; } /* inIn b.c */ int a[] = { 1, 2, 3, 4 }; /* UB 15 */ |
Compliant Solution (Incompatible Array Declarations)
This compliant solution declares a
as an array in a.c
and b.c
. :
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn a.c */ extern int a[]; int f(unsigned int i, int x) { int tmp = a[i]; a[i] = x; return tmp; } /* inIn b.c */ int a[] = { 1, 2, 3, 4 }; |
Anchor | ||||
---|---|---|---|---|
|
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 15. Furthermore, invoking the function results in is undefined behavior 41 with and typically has catastrophic effectsconsequences.
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn a.c */ extern int f(int a); /* UB 15 */ int g(int a) { return f(a); /* UB 41 */ } /* inIn b.c */ long f(long a) { /* UB 15 */ return a * 2; } |
Compliant Solution (Incompatible Function Declarations)
This compliant solution has compatible declarations of prototypes for the function f()
. :
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn a.c */ extern int f(int a); int g(int a) { return f(a); } /* inIn 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
:
Code Block | ||||
---|---|---|---|---|
| ||||
/* In a.c */
void buginf(const char *fmt, ...) {
/* ... */
}
/* In b.c */
void buginf(); |
Although this code appears to be well defined because of the prototype-less declaration of buginf()
, it exhibits undefined behavior in accordance with the C Standard, 6.7.7.4, paragraph 14 [ISO/IEC 9899:2024],
For two function types to be compatible, both shall specify compatible return types. Moreover, the parameter type lists shall agree in the number of parameters and in use of the final ellipsis; corresponding parameters shall have compatible types. In 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 this compliant solution, the prototype for the function buginf()
is included in the scope in the source file where it will be used:
Code Block | ||||
---|---|---|---|---|
| ||||
/* In a.c */ void buginf(const char *fmt, ...) { /* ... */ } /* In b.c */ void buginf(const char *fmt, ...); |
Anchor | ||||
---|---|---|---|---|
|
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
...
. 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 undefined behavior 31. It results in two incompatible declarations of the same function. (See undefined behavior 15.) In addition, invoking the function leads to undefined behavior 41 with typically catastrophic effects.
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn bash/bashline.h */ /* UB 15, UB 31 */ extern char * bash_groupname_completion_function(const char *, int); /* UB 15 */ /* inIn a.c */ #include <bashline"bashline.h>h" void f(const char *s, int i) { bash_groupname_completion_function(s, i); /* UB 41 */ } /* inIn b.c */ int bash_groupname_completion_funcfunct; /* UB 15, UB 31 */ |
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.
Code Block | ||||
---|---|---|---|---|
| ||||
/* inIn bash/bashline.h */ extern char * bash_groupname_completion(const char *, int); /* inIn a.c */ #include <bashline"bashline.h>h" void f(const char *s, int i) { bash_groupname_completion(s, i); } /* inIn b.c */ int bash_groupname_completion_funcfunct; |
Exceptions
...
Risk Assessment
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
DCL40-C | Low | Unlikely | Medium | P2 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| type-compatibility type-compatibility-link distinct-extern | Fully checked | ||||||
Axivion Bauhaus Suite |
| CertC-DCL40 | Fully implemented | ||||||
CodeSonar |
| LANG.STRUCT.DECL.IF LANG.STRUCT.DECL.IO | Inconsistent function declarations Inconsistent object declarations | ||||||
Coverity |
| MISRA C 2012 Rule 8.4 | Implemented | ||||||
Cppcheck Premium |
| premium-cert-dcl40-c | Partially implemented | ||||||
Helix QAC |
| C0776, C0778, C0779, C0789, C1510 C++1510 | Fully implemented | ||||||
Klocwork |
| MISRA.FUNC.NOPROT.DEF.2012 | Fully implemented | ||||||
LDRA tool suite | 8.5.4 | 1 X, 17 D | Partially implemented | ||||||
Parasoft C/C++test |
| CERT_C-DCL40-a | All declarations of an object or function shall have compatible types | ||||||
Parasoft Insure++ | Runtime analysis | ||||||||
PC-lint Plus |
| 18, 621, 793, 4376 | Fully supported | ||||||
Polyspace Bug Finder |
| Checks for declaration mismatch (rule fully covered) | |||||||
RuleChecker |
| type-compatibility type-compatibility-link distinct-extern
| Fully checked | ||||||
TrustInSoft Analyzer |
| incompatible declaration | Exhaustively verified. |
Related Guidelines
Key here (explains table format and definitions)
Taxonomy | Taxonomy item | Relationship |
---|---|---|
ISO/IEC TS 17961 |
Code Block | ||||
---|---|---|---|---|
| ||||
/* a.c: */
int x = 0; /* the definition */
/* b.c: */
extern char x; /* incompatible declaration */
/* but no other references to 'x' */
|
Related Guidelines
Declaring the same function or object in incompatible ways [funcdecl] | Prior to 2018-01-12: CERT: Unspecified Relationship | |
MISRA C:2012 | Rule 8.4 (required) | Prior to 2018-01-12: CERT: Unspecified Relationship |
Bibliography
[Hatton 1995] | Section 2.8.3 |
...
[ISO/IEC 9899:2011] | J.2, "Undefined Behavior" |
[ISO/IEC 9899:2024] | 6.7.7.4 "Function Declarators" |
...