C语言：头文件中实现的函数该如何选用extern/inline/static？

很多人写头文件内的函数实现时，对C语言的inline规则存在普遍误解——C语言的inline语义和C++完全不同：
单独添加inline关键字的函数定义，仅向编译器传递“可以尝试内联展开”的优化提示，不会生成外部可见的全局函数实体。如果编译时优化等级较低、函数体过于复杂无法内联、或者代码中需要获取函数地址，编译器就会尝试链接这个函数的全局符号，但因为没有任何编译单元生成过这个符号，最终就会触发undefined reference的链接错误，这就是该类场景下常见的链接错误根源。

直接把extern inline的函数定义写在头文件中，单文件场景下确实可以正常编译：

• 这个写法在C标准中的语义是，函数拥有外部链接，会生成实打实的全局函数实体，同时允许编译器在当前编译单元内对函数做内联展开。
  但这个写法存在致命缺陷：只要这个头文件被两个及以上的.c源文件包含，每个编译单元都会生成一份独立的、外部链接的max函数实体，链接器会直接报multiple definition的重复定义错误。单文件测试场景下能正常编译，只是因为没有多文件引入的符号冲突，一旦项目规模稍大，增加第二个包含foo.h的源文件，编译就会立刻失败。

针对“在头文件中实现简易代码共享”的需求，三种关键字组合的适用边界非常清晰：

• static inline
  这是最匹配该需求的写法。static关键字会把函数的链接属性从外部链接改成内部链接，相当于每个包含这个头文件的.c源文件，都会拥有一份属于自己的、私有的max函数副本，编译器可以自由对它做内联展开，既不会出现“找不到全局符号”的链接错误，也不会出现多文件包含时的重复定义问题。
  唯一的轻微开销是每个用到该函数的目标文件会附带一份极小的私有函数副本，对于max这类几行的工具函数来说，这点开销完全可以忽略，绝大多数标准库内的小型工具函数都是采用这种头文件内static inline的写法实现的。
• 单独inline
  这个写法不适合头文件直接带函数体的场景。它的标准使用流程是：头文件中只写inline的函数声明（不带函数体），再单独创建一个对应的.c源文件，在这个.c文件中写带函数体的extern inline定义。这样所有包含头文件的.c文件都可以在本单元内联展开函数，而单独的.c文件会生成一份全局可见的函数实体，供所有编译单元在无法内联时调用。但这种写法需要额外维护一个独立的.c文件，完全违背了“头文件简易共享”的初衷，性价比很低。
• extern inline
  这个组合绝对不能直接写在头文件里，它的唯一正确放置位置是上面提到的、那个专门用来生成全局函数实体的.c源文件中。把头文件里的实现换成extern inline的写法，本质是踩了单文件测试的盲区，项目稍复杂就会触发重复定义问题。

补充提醒：很多人混淆C和C的inline规则——在C中，只要是带inline标记的函数，就算在多个编译单元中出现完全相同的定义，链接器会自动去重不会报重复定义，但C语言完全没有这个机制，直接把C++的inline写法搬到C项目中，一定会踩坑。

对于示例中的代码，只需要把foo.h中的max函数定义改成static inline int max(int x, int y) { return x < y ? y : x; }，就可以完全解决所有链接问题，同时不影响内联优化的效果。

内容的提问来源于stack exchange，提问作者Christian Doucette