Try to compile the following simple C program in C99 mode with GCC:<\/p>\n
inline void foo() {}\r\nint main(void)\r\n{\r\n foo();\r\n}<\/pre>\nThe results may surprise you:<\/p>\n
$ gcc test.c -std=c99\r\n\/tmp\/ccWN4GRh.o: In function `main':\r\ntest.c:(.text+0xa): undefined reference to `foo'\r\ncollect2: ld returned 1 exit status<\/pre>\nHuh? The function’s right there!<\/p>\n
Well it turns out that this is not a bug in GCC, but a peculiarity in the way the inline<\/code> keyword is defined by the C99 standard. Basically, a function declared inline<\/code> without either of the extern<\/code> or static<\/code> linkage specifiers only creates an inline definition of that function, not an external definition<\/strong>.<\/p>\nWhen presented with a call to such a function, the compiler can choose to call either the inline definition or the external definition. If it chooses the external definition, and such an external definition doesn’t exist, we get a linker error, as in the above example. In the dry words of the standard:<\/p>\n
ISO\/IEC 9899:1999 \u00a76.7.4\/6:<\/p>\n
Any function with internal linkage can be an inline function. For a function with external linkage, the following restrictions apply: If a function is declared with an inline<\/strong> function specifier, then it shall also be defined in the same translation unit. If all of the file scope declarations for a function in a translation unit include the inline<\/strong> function specifier without extern<\/strong>, then the definition in that translation unit is an inline definition<\/em>. An inline definition does not provide an external definition for the function, and does not forbid an external definition in another translation unit. An inline definition provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. It is unspecified whether a call to the function uses the inline definition or the external definition.120)<\/sup><\/p><\/blockquote>\nSo there are three ways to fix this code:<\/p>\n
\n- Give
foo<\/code> internal linkage (by declaring it static<\/code>) and avoid the above clause entirely\n- Declare
foo<\/code> as extern<\/code>\n- Provide a separate external definition for
foo<\/code> in another translation unit (that is, another source file)\n<\/ol>\nI would strongly recommend against solution #3, since then your code base will have two separate definitions of foo<\/code>, which will be very confusing for people reading your code. It’s very easy for them to get out of sync, if somebody changes one definition but forgets to change the other, which makes for some insidious bugs (such as working correctly in a debug build but not in a release build, or vice-versa).<\/p>\n