@@ -78,8 +78,9 @@ <h2 id="c">C compatibility</h3>
78
78
< h3 id ="inline "> C99 inline functions</ h3 >
79
79
<!-- ======================================================================= -->
80
80
< p > By default, Clang builds C code according to the C99 standard,
81
- which provides different inlining semantics than GCC's default
82
- behavior. For example, when compiling the following code with no optimization:</ p >
81
+ which provides different semantics for the < code > inline</ code > keyword
82
+ than GCC's default behavior. For example, consider the following
83
+ code:</ p >
83
84
< pre >
84
85
inline int add(int i, int j) { return i + j; }
85
86
@@ -89,36 +90,54 @@ <h3 id="inline">C99 inline functions</h3>
89
90
}
90
91
</ pre >
91
92
92
- < p > In C99, this is an incomplete (incorrect) program because there is
93
- no external definition of the < code > add</ code > function: the inline
94
- definition is only used for optimization, if the compiler decides to
95
- perform inlining. Therefore, we will get a (correct) link-time error
96
- with Clang, e.g.:</ p >
93
+ < p > In C99, < code > inline</ code > means that a function's definition is
94
+ provided only for inlining, and that there is another definition
95
+ (without < code > inline</ code > ) somewhere else in the program. That
96
+ means that this program is incomplete, because if < code > add</ code >
97
+ isn't inlined (for example, when compiling without optimization), then
98
+ < code > main</ code > will have an unresolved reference to that other
99
+ definition. Therefore we'll get a (correct) link-time error like this:</ p >
97
100
98
101
< pre >
99
102
Undefined symbols:
100
103
"_add", referenced from:
101
104
_main in cc-y1jXIr.o
102
105
</ pre >
103
106
107
+ < p > By contrast, GCC's default behavior follows the GNU89 dialect,
108
+ which is the C89 standard plus a lot of extensions. C89 doesn't have
109
+ an < code > inline</ code > keyword, but GCC recognizes it as an extension
110
+ and just treats it as a hint to the optimizer.</ p >
111
+
104
112
< p > There are several ways to fix this problem:</ p >
105
113
106
114
< ul >
107
115
< li > Change < code > add</ code > to a < code > static inline</ code >
108
- function. Static inline functions are always resolved within the
109
- translation unit, so you won't have to add an external, non-inline
110
- definition of the function elsewhere in your program.</ li >
111
-
112
- < li > Provide an external (non-inline) definition of < code > add</ code >
113
- somewhere in your program.</ li >
114
-
116
+ function. This is usually the right solution if only one
117
+ translation unit needs to use the function. < code > static
118
+ inline</ code > functions are always resolved within the translation
119
+ unit, so you won't have to add a non-< code > inline</ code > definition
120
+ of the function elsewhere in your program.</ li >
121
+
122
+ < li > Remove the < code > inline</ code > keyword from this definition of
123
+ < code > add</ code > . The < code > inline</ code > keyword is not required
124
+ for a function to be inlined, nor does it guarantee that it will be.
125
+ Some compilers ignore it completely. Clang treats it as a mild
126
+ suggestion from the programmer.</ li >
127
+
128
+ < li > Provide an external (non-< code > inline</ code > ) definition
129
+ of < code > add</ code > somewhere else in your program. The two
130
+ definitions must be equivalent!</ li >
131
+
115
132
< li > Compile with the GNU89 dialect by adding
116
133
< code > -std=gnu89</ code > to the set of Clang options. This option is
117
134
only recommended if the program source cannot be changed or if the
118
135
program also relies on additional C89-specific behavior that cannot
119
136
be changed.</ li >
120
137
</ ul >
121
138
139
+ < p > All of this only applies to C code; the meaning of < code > inline</ code >
140
+ in C++ is very different from its meaning in either GNU89 or C99.</ p >
122
141
123
142
<!-- ======================================================================= -->
124
143
< h3 id ="vector_builtins "> "missing" vector __builtin functions</ h3 >
0 commit comments