You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: c/cert/src/rules/DCL40-C/ExcessLengthNamesIdentifiersNotDistinct.md
+211-2Lines changed: 211 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,218 @@ This query implements the CERT-C rule DCL40-C:
5
5
> Do not create incompatible declarations of the same function or object
6
6
7
7
8
-
## CERT
9
8
10
-
** REPLACE THIS BY RUNNING THE SCRIPT `scripts/help/cert-help-extraction.py`**
9
+
## Description
10
+
11
+
Two or more incompatible declarations of the same function or object must not appear in the same program because they result in [undefined behavior](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-undefinedbehavior). The C Standard, 6.2.7, mentions that two types may be distinct yet compatible and addresses precisely when two distinct types are compatible.
12
+
13
+
The C Standard identifies four situations in which [undefined behavior (UB)](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-undefinedbehavior) may arise as a result of incompatible declarations of the same function or object:
14
+
15
+
<table> <tbody> <tr> <th> UB </th> <th> Description </th> <th> Code </th> </tr> <tr> <td> <a> 15 </a> </td> <td> <em> Two declarations of the same object or function specify types that are not compatible (6.2.7). </em> </td> <td> All noncompliant code in this guideline </td> </tr> <tr> <td> <a> 31 </a> </td> <td> <em> Two identifiers differ only in nonsignificant characters (6.4.2.1). </em> </td> <td> <a> Excessively Long Identifiers </a> </td> </tr> <tr> <td> <a> 37 </a> </td> <td> <em> An object has its stored value accessed other than by an lvalue of an allowable type (6.5). </em> </td> <td> <a> Incompatible Object Declarations </a> <a> Incompatible Array Declarations </a> </td> </tr> <tr> <td> <a> 41 </a> </td> <td> <em> 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). </em> </td> <td> <a> Incompatible Function Declarations </a> <a> Excessively Long Identifiers </a> </td> </tr> </tbody> </table>
16
+
Although the effect of two incompatible declarations simply appearing in the same program may be benign on most [implementations](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-implementation), 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](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-lvalue) of a type that is incompatible with the object definition may range from unintended information exposure to memory overwrite to a hardware trap.
17
+
18
+
19
+
## Noncompliant Code Example (Incompatible Object Declarations)
20
+
21
+
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 15](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_15). Furthermore, accessing the object using an [lvalue](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-lvalue) of an incompatible type, as shown in function `f()`, is [undefined behavior 37](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_37) with possible observable results ranging from unintended information exposure to memory overwrite to a hardware trap.
This compliant solution has compatible declarations of the variable `i`:
39
+
40
+
```cpp
41
+
/* In a.c */
42
+
extern int i;
43
+
44
+
int f(void) {
45
+
return ++i;
46
+
}
47
+
48
+
/* In b.c */
49
+
int i;
50
+
```
51
+
52
+
## Noncompliant Code Example (Incompatible Array Declarations)
53
+
54
+
In this noncompliant code example, the variable `a` is declared to have a pointer type in file `a.c` but defined to have an array type in file `b.c`. The two declarations are incompatible, resulting in [undefined behavior 15](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_15). As before, accessing the object in function `f()` is [undefined behavior 37](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_37) with the typical effect of triggering a hardware trap.
This compliant solution declares `a` as an array in `a.c` and `b.c`:
74
+
75
+
```cpp
76
+
/* In a.c */
77
+
extern int a[];
78
+
79
+
int f(unsigned int i, int x) {
80
+
int tmp = a[i];
81
+
a[i] = x;
82
+
return tmp;
83
+
}
84
+
85
+
/* In b.c */
86
+
int a[] = { 1, 2, 3, 4 };
87
+
```
88
+
89
+
## Noncompliant Code Example (Incompatible Function Declarations)
90
+
91
+
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](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_15). Furthermore, invoking the function is [undefined behavior 41](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_41) and typically has catastrophic consequences.
92
+
93
+
```cpp
94
+
/* In a.c */
95
+
externintf(int a); /* UB 15 */
96
+
97
+
int g(int a) {
98
+
return f(a); /* UB 41 */
99
+
}
100
+
101
+
/* In b.c */
102
+
long f(long a) { /* UB 15 */
103
+
return a * 2;
104
+
}
105
+
106
+
```
107
+
108
+
## Compliant Solution (Incompatible Function Declarations)
109
+
110
+
This compliant solution has compatible prototypes for the function `f()`:
111
+
112
+
```cpp
113
+
/* In a.c */
114
+
extern int f(int a);
115
+
116
+
int g(int a) {
117
+
return f(a);
118
+
}
119
+
120
+
/* In b.c */
121
+
int f(int a) {
122
+
return a * 2;
123
+
}
124
+
```
125
+
126
+
## Noncompliant Code Example (Incompatible Variadic Function Declarations)
127
+
128
+
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`:
129
+
130
+
```cpp
131
+
/* In a.c */
132
+
voidbuginf(const char *fmt, ...) {
133
+
/* ... */
134
+
}
135
+
136
+
/* In b.c */
137
+
void buginf();
138
+
```
139
+
Although this code appears to be well defined because of the prototype-less declaration of `buginf()`, it exhibits [undefined behavior](https://wiki.sei.cmu.edu/confluence/display/c/BB.+Definitions#BB.Definitions-undefinedbehavior) in accordance with the C Standard, 6.7.6.3, paragraph 15 \[[ISO/IEC 9899:2011](https://wiki.sei.cmu.edu/confluence/display/c/AA.+Bibliography#AA.Bibliography-ISO-IEC9899-2011)\],
140
+
141
+
> For two function types to be compatible, both shall specify compatible return types. Moreover, the parameter type lists, if both are present, shall agree in the number of parameters and in use of the ellipsis terminator; corresponding parameters shall have compatible types. If one type has a parameter type list and the other type is specified by a function declarator that is not part of a function definition and that contains an empty identifier list, the parameter list shall not have an ellipsis terminator and the type of each parameter shall be compatible with the type that results from the application of the default argument promotions.
142
+
143
+
144
+
## Compliant Solution (Incompatible Variadic Function Declarations)
145
+
146
+
In this compliant solution, the prototype for the function `buginf()` is included in the scope in the source file where it will be used:
147
+
148
+
```cpp
149
+
/* In a.c */
150
+
void buginf(const char *fmt, ...) {
151
+
/* ... */
152
+
}
153
+
154
+
/* In b.c */
155
+
void buginf(const char *fmt, ...);
156
+
```
157
+
158
+
## Noncompliant Code Example (Excessively Long Identifiers)
159
+
160
+
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](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_31). It results in two incompatible declarations of the same function. (See [undefined behavior 15](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_15).) In addition, invoking the function leads to [undefined behavior 41](https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_41) with typically catastrophic effects.
int bash_groupname_completion_funct; /* UB 15, UB 31 */
176
+
177
+
```
178
+
NOTE: The identifier `bash_groupname_completion_function` referenced here was taken from GNU [Bash](http://www.gnu.org/software/bash/), version 3.2.
179
+
180
+
## Compliant Solution (Excessively Long Identifiers)
181
+
182
+
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.
[Key here](https://wiki.sei.cmu.edu/confluence/display/c/How+this+Coding+Standard+is+Organized#HowthisCodingStandardisOrganized-RelatedGuidelines) (explains table format and definitions)
212
+
213
+
<table> <tbody> <tr> <th> Taxonomy </th> <th> Taxonomy item </th> <th> Relationship </th> </tr> <tr> <td> <a> ISO/IEC TS 17961 </a> </td> <td> Declaring the same function or object in incompatible ways \[funcdecl\] </td> <td> Prior to 2018-01-12: CERT: Unspecified Relationship </td> </tr> <tr> <td> <a> MISRA C:2012 </a> </td> <td> Rule 8.4 (required) </td> <td> Prior to 2018-01-12: CERT: Unspecified Relationship </td> </tr> </tbody> </table>
0 commit comments