Editing Inline function (section)

=== C99 ===
In C99, a function defined <code>inline</code> will never, and a function defined <code>extern inline</code> will always, emit an externally visible function. Unlike in C++, there is no way to ask for an externally visible function shared among translation units to be emitted only if required.

If <code>inline</code> declarations are mixed with <code>extern inline</code> declarations or with unqualified declarations (ie., without <code>inline</code> qualifier or storage class), the translation unit must contain a definition (no matter whether unqualified, <code>inline</code>, or <code>extern inline</code>) and an externally visible function will be emitted for it.

A function defined <code>inline</code> requires exactly one function with that name somewhere else in the program which is either defined <code>extern inline</code> or without qualifier. If more than one such definition is provided in the whole program, the linker will complain about duplicate symbols. If, however, it is lacking, the linker does not necessarily complain, because, if all uses could be inlined, it is not needed. But it may complain, since the compiler can always ignore the <code>inline</code> qualifier and generate calls to the function instead, as typically happens if the code is compiled without optimization. (This may be the desired behavior, if the function is supposed to be inlined everywhere by all means, and an error should be generated if it is not.)  A convenient way is to define the <code>inline</code> functions in header files and create one .c file per function, containing an <code>extern inline</code> declaration for it and including the respective header file with the definition. It does not matter whether the declaration is before or after the include.

To prevent [[unreachable code]] from being added to the final executable if all uses of a function were inlined, it is advised<ref name="gcc-inline"/> to put the object files of all such .c files with a single <code>extern inline</code> function into a [[static library]] file, typically with <code>ar rcs</code>, then link against that library instead of the individual object files. That causes only those object files to be linked that are actually needed, in contrast to linking the object files directly, which causes them to be always included in the executable. However, the library file must be specified after all the other object files on the linker command line, since calls from object files specified after the library file to the functions will not be considered by the linker. Calls from <code>inline</code> functions to other <code>inline</code> functions will be resolved by the linker automatically (the <code>s</code> option in <code>ar rcs</code> ensures this).

An alternative solution is to use link time optimization instead of a library. gcc provides the flag <code>-Wl,--gc-sections</code> to omit sections in which all functions are unused. This will be the case for object files containing the code of a single unused <code>extern inline</code> function. However, it also removes any and all other unused sections from all other object files, not just those related to unused <code>extern inline</code> functions. (It may be desired to link functions into the executable that are to be called by the programmer from the debugger rather than by the program itself, eg., for examining the internal state of the program.) With this approach, it is also possible to use a single .c file with all <code>extern inline</code> functions instead of one .c file per function. Then the file has to be compiled with <code>-fdata-sections -ffunction-sections</code>. However, the gcc manual page warns about that, saying "Only use these options when there are significant benefits from doing so."

Some recommend an entirely different approach, which is to define functions as <code>static inline</code> instead of <code>inline</code> in header files.<ref name="inline-c99-vs-gnu"/> Then, no unreachable code will be generated. However, this approach has a drawback in the opposite case: Duplicate code will be generated if the function could not be inlined in more than one translation unit. The emitted function code cannot be shared among translation units because it must have different addresses. This is another drawback; taking the address of such a function defined as <code>static inline</code> in a header file will yield different values in different translation units. Therefore, <code>static inline</code> functions should only be used if they are used in only one translation unit, which means that they should only go to the respective .c file, not to a header file.