Is "inline" without "static" or "extern" ever useful in C99?

Question

When I try to build this code

inline void f() {}  int main() {     f(); } 

using the command line

gcc -std=c99 -o a a.c 

I get a linker error (undefined reference to f). The error vanishes if I use static inline or extern inline instead of just inline, or if I compile with -O (so the function is actually inlined).

This behaviour seems to be defined in paragraph 6.7.4 (6) of the C99 standard:

If all of the file scope declarations for a function in a translation unit include the inline function specifier without extern, then the definition in that translation unit is an inline definition. 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.

If I understand all this correctly, a compilation unit with a function defined inline as in the above example only compiles consistently if there is also an external function with the same name, and I never know if my own function or the external function is called.

Isn't this behaviour completely daft? Is it ever useful to define a function inline without static or extern in C99? Am I missing something?

Summary of answers

Of course I was missing something, and the behaviour isn't daft. :)

As Nemo explains, the idea is to put the definition of the function

inline void f() {} 

in the header file and only a declaration

extern inline void f(); 

in the corresponding .c file. Only the extern declaration triggers the generation of externally visible binary code. And there is indeed no use of inline in a .c file -- it's only useful in headers.

As the rationale of the C99 committee quoted in Jonathan's answer explicates, inline is all about compiler optimisations that require the definition of a function to be visible at the site of a call. This can only be achieved by putting the definition in the header, and of course a definition in a header must not emit code every time it is seen by the compiler. But since the compiler is not forced to actually inline a function, an external definition must exist somewhere.

Answer 1

Actually this excellent answer also answers your question, I think:

What does extern inline do?

The idea is that "inline" can be used in a header file, and then "extern inline" in a .c file. "extern inline" is just how you instruct the compiler which object file should contain the (externally visible) generated code.

[update, to elaborate]

I do not think there is any use for "inline" (without "static" or "extern") in a .c file. But in a header file it makes sense, and it requires a corresponding "extern inline" declaration in some .c file to actually generate the stand-alone code.

Answer 2

From the standard (ISO/IEC 9899:1999) itself:

Appendix J.2 Undefined Behaviour

• ...
• A function with external linkage is declared with an inline function specifier, but is not also defined in the same translation unit (6.7.4).
• ...

---

The C99 Committee wrote a Rationale, and it says:

6.7.4 Function specifiers

A new feature of C99: The inline keyword, adapted from C++, is a function-specifier that can be used only in function declarations. It is useful for program optimizations that require the definition of a function to be visible at the site of a call. (Note that the Standard does not attempt to specify the nature of these optimizations.)

Visibility is assured if the function has internal linkage, or if it has external linkage and the call is in the same translation unit as the external definition. In these cases, the presence of the inline keyword in a declaration or definition of the function has no effect beyond indicating a preference that calls of that function should be optimized in preference to calls of other functions declared without the inline keyword.

Visibility is a problem for a call of a function with external linkage where the call is in a different translation unit from the function’s definition. In this case, the inline keyword allows the translation unit containing the call to also contain a local, or inline, definition of the function.

A program can contain a translation unit with an external definition, a translation unit with an inline definition, and a translation unit with a declaration but no definition for a function. Calls in the latter translation unit will use the external definition as usual.

An inline definition of a function is considered to be a different definition than the external definition. If a call to some function func with external linkage occurs where an inline definition is visible, the behavior is the same as if the call were made to another function, say __func, with internal linkage. A conforming program must not depend on which function is called. This is the inline model in the Standard.

A conforming program must not rely on the implementation using the inline definition, nor may it rely on the implementation using the external definition. The address of a function is always the address corresponding to the external definition, but when this address is used to call the function, the inline definition might be used. Therefore, the following example might not behave as expected.

inline const char *saddr(void) {     static const char name[] = "saddr";     return name; } int compare_name(void) {     return saddr() == saddr(); // unspecified behavior } 

Since the implementation might use the inline definition for one of the calls to saddr and use the external definition for the other, the equality operation is not guaranteed to evaluate to 1 (true). This shows that static objects defined within the inline definition are distinct from their corresponding object in the external definition. This motivated the constraint against even defining a non-const object of this type.

Inlining was added to the Standard in such a way that it can be implemented with existing linker technology, and a subset of C99 inlining is compatible with C++. This was achieved by requiring that exactly one translation unit containing the definition of an inline function be specified as the one that provides the external definition for the function. Because that specification consists simply of a declaration that either lacks the inline keyword, or contains both inline and extern, it will also be accepted by a C++ translator.

Inlining in C99 does extend the C++ specification in two ways. First, if a function is declared inline in one translation unit, it need not be declared inline in every other translation unit. This allows, for example, a library function that is to be inlined within the library but available only through an external definition elsewhere. The alternative of using a wrapper function for the external function requires an additional name; and it may also adversely impact performance if a translator does not actually do inline substitution.

Second, the requirement that all definitions of an inline function be “exactly the same” is replaced by the requirement that the behavior of the program should not depend on whether a call is implemented with a visible inline definition, or the external definition, of a function. This allows an inline definition to be specialized for its use within a particular translation unit. For example, the external definition of a library function might include some argument validation that is not needed for calls made from other functions in the same library. These extensions do offer some advantages; and programmers who are concerned about compatibility can simply abide by the stricter C++ rules.

Note that it is not appropriate for implementations to provide inline definitions of standard library functions in the standard headers because this can break some legacy code that redeclares standard library functions after including their headers. The inline keyword is intended only to provide users with a portable way to suggest inlining of functions. Because the standard headers need not be portable, implementations have other options along the lines of:

#define abs(x) __builtin_abs(x) 

or other non-portable mechanisms for inlining standard library functions.