An identifier can be Linkage can make an identifier declared in different scopes or declared multiple times within the same scope refer to the same object or function. Identifiers are classified as externally linked, internally linked, or not - linked.
An identifier that is classified as externally linked can include:
...
These three kinds of linkage have the following characteristics [Kirch-Prinz 2002]:
- External linkage: An identifier with external linkage represents the same object or function throughout the entire program, that is, in all compilation units and libraries belonging to the program. The identifier is available to the linker. When a second declaration of the same identifier with external linkage occurs, the linker associates the identifier with the same object or function.
- Internal linkage: An identifier with internal linkage represents the same object or function within a given translation unit. The linker has no information about identifiers with internal linkage. Consequently, these identifiers are internal to the translation unit.
- No linkage: If an identifier has no linkage, then any further declaration using the identifier declares something new, such as a new variable or a new type.
According to the C Standard, 6.2.2 paragraph 3 [ISO/IEC 9899:2024], linkage is determined as follows:
If the declaration of a file scope identifier for:
- an object contains any of the storage-class specifiersstatic
orcontexpr;
- or, a function contains the storage-class specifier
static
,then the identifier has internal linkage.
For an identifier declared with the storage-class specifier
extern
...
in a scope in which a prior declaration of that identifier is visible, if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage.
If the declaration of an identifier for a function has no storage-class specifier, its linkage is determined exactly as if it were declared with the storage-class specifier
extern
. If the declaration of an identifier for an object has file scope and does not contain
An identifier that is classified as internally linked can include:
...
the storage-class specifier
static
...
An identifer that is classified as not-linked can include:
or
contexpr
, its linkage is external.The following identifiers have no linkage: an
...
identifier declared to be anything other than an object or a function
...
; an identifier declared to be a function parameter
...
; a block scope identifier for an object declared without the storage-class specifier
extern
.
(* If a prior declaration is visible and has no linkage, the latter declaration is externally linked.
If a prior declaration is visible and has either internal or external linkage, the latter declaration is classified with the same linkage as the prior declaration.)
Use of an identifier (within one translational translation unit) classified as both internally and externally linked causes is undefined behavior. (See also undefined behavior 8.) A translational translation unit includes the sourcefile source file together with its headers , and all sourcefiles source files included via the preprocessing directive #include
.
The following table identifies the linkage assigned to an object that is declared twice in a single translation unit. The column designates the first declaration, and the row designates the redeclaration.
...
Noncompliant Code Example
In this non-compliant example, the first declaration of the identifier x would be classified as externally linked. The second declaration is internally linked. Future use of this identifier can cause undefined behavior.int x; // externally linked
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
int main () { |
Compliant Solution
In this compliant solution, more descriptive identifier names are used, so as to avoid this problem.int externalInt; // externally linked
noncompliant code example, i2
and i5
are defined as having both internal and external linkage. Future use of either identifier results in undefined behavior.
Code Block | ||||
---|---|---|---|---|
| ||||
int i1 = 10; /* Definition, external linkage */
static int i2 = 20; /* Definition, internal linkage */
extern int i3 = 30; /* Definition, external linkage */
int i4; /* Tentative definition, external linkage */
static int i5; /* Tentative definition, internal linkage */
int i1; /* Valid tentative definition */
int i2; /* Undefined, linkage disagreement with previous */
int i3; /* Valid tentative definition */
int i4; /* Valid tentative definition */
int i5; /* Undefined, linkage disagreement with previous */
int main(void) {
/* ... */
return 0;
}
|
Implementation Details
Microsoft Visual Studio 2013 issues no warnings about this code, even at the highest diagnostic levels.
GCC and Clang 14 both generate fatal diagnostics for the conflicting definitions of i2
and i5
.
Compliant Solution
This compliant solution does not include conflicting definitions:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
int i1 = 10; /* Definition, external linkage */
static int i2 = 20; /* Definition, internal linkage */
extern int i3 = 30; /* Definition, external linkage */
int i4; /* Tentative definition, external linkage */
static int i5; /* Tentative definition, internal linkage */
int main(void) {
/* ... */
return 0;
}
| ||||||||
Panel | ||||||||
| ||||||||
int main () { static int internalInt; // internally linked ... } |
Risk Assessment
Use of an identifier classified as both internally and externally linked causes is undefined behavior in the program. However, it would be highly unlikely that an attacker could exploit this behavior to run arbitrary code.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
DCL05-A
1 (low)
2 (probable)
3 (low)
P6
L2
DCL36-C | Medium | Probable | Medium | P8 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| static-function-declaration static-object-declaration | Partially checked | ||||||
Axivion Bauhaus Suite |
| CertC-DCL36 | Fully implemented | ||||||
CodeSonar |
| LANG.STRUCT.DECL.NOEXT | Missing External Declaration | ||||||
Coverity |
| PW.LINKAGE_CONFLICT | Implemented | ||||||
Cppcheck Premium |
| premium-cert-dcl36-c | Fully implemented | ||||||
| CC2.DCL36 | Fully implemented | |||||||
GCC |
| ||||||||
Helix QAC |
| C0625 | Fully implemented | ||||||
Klocwork |
| MISRA.FUNC.STATIC.REDECL | Fully implemented | ||||||
LDRA tool suite |
| 461 S, 575 S, 2 X | Fully implemented | ||||||
PC-lint Plus |
| 401, 839, 1051 | Fully supported | ||||||
Splint |
| ||||||||
Parasoft C/C++test |
| CERT_C-DCL36-a | Identifiers shall not simultaneously have both internal and external linkage in the same translation unit | ||||||
Polyspace Bug Finder |
| Checks for inconsistent use of static and extern in object declarations (rule partially covered) | |||||||
RuleChecker |
| static-function-declaration static-object-declaration | Partially checked | ||||||
TrustInSoft Analyzer |
| non-static declaration follows static declaration | Partially verified. |
Related Vulnerabilities
Search for Examples of vulnerabilities resulting from the violation of this rule can be found on the CERT website.
Related Guidelines
Key here (explains table format and definitions)
Taxonomy | Taxonomy item | Relationship |
---|---|---|
MISRA C:2012 | Rule 8.2 (required) | Prior to 2018-01-12: CERT: Unspecified Relationship |
MISRA C:2012 | Rule 8.4 (required) | Prior to 2018-01-12: CERT: Unspecified Relationship |
MISRA C:2012 | Rule 8. |
...
8 (required) | Prior to 2018-01-12: CERT: Unspecified Relationship | |
MISRA C:2012 | Rule 17.3 (mandatory) | Prior to 2018-01-12: CERT: Unspecified Relationship |
Bibliography
References
...
...
...
:2024] | 6.2.2, |
...
"Linkages |
...
of Identifiers" | |
[Kirch-Prinz 2002] |
...