gnu89和c99中的inline关键字的关系和差异

一、

这是一个很深入的问题，涉及 GCC 对 inline 的底层处理机制。

GCC 的 `inline` 扩展：体现在"符号发射规则"上

这是 GNU89 和 C99 最核心的差异点。

GNU89 的 `inline` 语义（GCC 自创）

在 -std=gnu89 下，GCC 对 inline 函数的规则是：

c 复制代码

// 某个 .h 头文件中
inline int add(int a, int b) 
{
    return a + b;
}

情况	GCC 的行为
编译器决定内联展开	不生成独立的函数符号（无外部符号）
编译器决定不内联（如函数太复杂）	不会自动生成一个可供链接的外部符号

后果：如果编译器不内联，链接器找不到符号 → 链接报错 undefined reference。

所以在 GNU89 下，你必须在某个 .c 文件里再提供一个外部定义：

c 复制代码

// 某个 .c 文件中，必须补充这一行来"兜底"
extern int add(int a, int b);  // 或直接写非inline的定义

这个行为是 GCC 自己发明的，C89 标准根本没有描述过这件事。

C99 的 `inline` 语义（标准化后改了规则）

C99 把规则反过来了：

c 复制代码

// .h 中
inline int add(int a, int b) { return a + b; }

编译器内联 → 没有外部符号（同上）
编译器不内联 → 也没有外部符号（同上）
但 C99 规定：你必须在恰好一个 .c 文件里提供 extern inline 定义作为"外部定义"，由链接器使用

c 复制代码

// 恰好一个 .c 文件中
extern inline int add(int a, int b);  // C99：这才是生成外部符号的那个

`static inline` 为什么两者都兼容？

回到你贴的代码：

c 复制代码

static inline my_uint64_t cmnN2H64_LE(my_uint64_t v64) { ... }

static 直接解决了上述所有麻烦：

复制代码

static = 每个编译单元各自拥有一份独立副本

不需要外部符号
不存在跨编译单元的链接问题
GNU89 / C99 / C++98 下语义完全一致

所以这个写法在 GNU89 时代就是绕开 inline 语义差异的标准惯用法，老项目里大量使用正是出于这个原因。

总结一句话

GCC 的扩展体现在：它自己规定了一套 inline 函数的符号发射规则 （内联成功则不发射符号，不内联则依赖外部兜底定义），这套规则既不是 C89 标准的内容，也和后来 C99 的标准化方案不同。static inline 则是绕过这一差异、实现跨标准兼容的惯用解法。

二、gnu89在什么时候支持inline的，inline的发展历史，inline出现的原因，inline并入c99遇到的阻力

下面按"时间线 + 语义差异 + 背后动机 + C99 并入时的阻力"来讲。

1. GNU89 支持 `inline`的时间

严格说，GNU89 不是 ISO C89/C90 标准本身 ，而是 GCC 的"C89/C90 + GNU 扩展"方言；inline 在这里属于 GNU C 扩展 ，不是 C89 标准关键字。GCC 文档明确说：GCC 有三套 inline 语义，其中一套用于 -std=gnu89、-fgnu89-inline 或带 gnu_inline 属性的声明；另一套用于 -std=c99 / -std=gnu99 及更新 C 标准；第三套用于 C++。 [gcc.gnu.org], [gnu.org]

如果问"-std=gnu89 这个模式里从什么时候有 inline"：可以保守地说，它是 GCC 很早期就有的 GNU C 扩展，远早于 C99 。GCC 4.2 文档已经把 GNU 传统 inline 称为当前实现，并说明 ISO C99 的 inline 与 GCC 当时实现存在重大差异，且 GCC 4.3 才会完整支持 C99 inline 语义。

所以实际历史是： [gcc.gnu.org], [gnu.org]

C89/C90 标准 ：没有 inline。
GNU C / GNU89 ：早就把 inline 作为扩展提供。
C99 ：把 inline 正式纳入标准。
GCC 4.3，2008-03-05 发布 ：在 -std=c99 / -std=gnu99 下切换到符合 C99 的 inline 语义；传统 GNU 语义仍可通过 -std=gnu89、-fgnu89-inline 或 gnu_inline 属性使用。 [gnu.org], [gnu.org]

一句话总结：GNU89 支持 inline 是作为 GNU 扩展早于 C99 就存在；但 GCC 真正让 C99 模式采用 C99 inline 语义，是 GCC 4.3。

2. `inline`优点

inline 的出现主要是为了解决 C 里一个长期矛盾：小函数想要函数的类型检查和作用域语义，但又不想承担函数调用开销。

传统 C 里如果想消除函数调用开销，常用宏：

c 复制代码

#define SQUARE(x) ((x) * (x))

但宏有很多问题：

c 复制代码

SQUARE(i++)

会展开成：

c 复制代码

((i++) * (i++))

这可能产生多次副作用。宏也没有函数级类型检查、没有正常的调试体验、作用域也粗糙。inline 的目标就是提供一种"像函数一样安全，但有机会像宏一样快"的机制。GCC 文档也把这一节标题写成 "An Inline Function is As Fast As a Macro"，并说明内联可以消除函数调用开销，还能让编译器在实参为常量时进一步做常量传播、分支消除等优化。 [gcc.gnu.org], [gcc.gnu.org]

所以 inline 的核心价值有三点：

减少调用开销 ：避免 call/return、栈帧建立、参数传递等成本。 [gcc.gnu.org]
保留函数语义：有类型检查、作用域、调试信息，比宏更安全。
给优化器更多上下文 ：函数体出现在调用点后，编译器可以做常量折叠、死代码消除、寄存器分配优化等。GCC 文档也提到实参常量可能让编译器简化内联后的代码。 [gcc.gnu.org]

不过 inline 不是命令，而是提示。编译器可以选择不内联；GCC 文档也说明有些函数特性会妨碍内联，比如可变参数、alloca、computed goto、嵌套函数、setjmp 等。 [gcc.gnu.org], [gcc.gnu.org]

3. C99 把 `inline` 纳入标准的原因

C99 的很多新特性，其实是把已经在编译器实践中成熟的扩展标准化。C99 引入了 inline 函数、混合声明与语句、long long、_Bool、复数、变长数组、// 注释等，其中不少已经在编译器中以扩展形式存在。 [en.wikipedia.org], [en.cppreference.com]

inline 被纳入 C99 的动机大概是：

C++ 已经有 inline；
GNU C 等实现已经长期支持类似机制；
宏在性能敏感代码中常用，但安全性差；
标准 C 需要一种可移植的、小函数优化表达方式。

但 C99 的问题不在"要不要有 inline"，而在于：如果一个内联函数放在头文件里，被多个 .c 文件包含，什么时候生成真正的外部符号？谁负责提供那个唯一的外部定义？

这就是 C99 inline 设计里最麻烦的部分。

4. GNU89 `inline` 和 C99 `inline` 区别

最容易踩坑的是：GNU89 和 C99 对 inline / extern inline 的含义几乎反过来了 。GCC 5 移植文档明确总结：在 C99 语义下，inline 不生成外部可见函数；如果本翻译单元引用它，需要另一个翻译单元提供外部定义；而 C99 的 extern inline 会生成外部可见函数，这与 GNU89 的 inline 对应。 [gnu.org]

GNU89 传统语义大致是：

c 复制代码

inline int f(int x) {
    return x + 1;
}

倾向于：生成一个外部定义，也可用于内联。

c 复制代码

extern inline int f(int x) {
    return x + 1;
}

倾向于：只用于内联，不生成外部定义。

C99 语义大致是：

c 复制代码

inline int f(int x) {
    return x + 1;
}

这是一个 inline definition ，本身不提供外部定义。如果编译器没有内联某个调用，链接器可能需要在别处找到一个真正的外部定义。Stack Overflow 上常见的 -std=gnu99 下 inline 函数出现 undefined reference，就是这个原因。 [stackoverflow.com], [gnu.org]

c 复制代码

extern inline int f(int x) {
    return x + 1;
}

在 C99 下反而会提供外部可见定义。GCC 4.3 的 porting 文档专门警告：extern inline 在 -std=c99 / -std=gnu99 下含义改变，之前不生成定义的代码，现在会生成定义，从而可能导致 multiple definition。 [gnu.org]

这就是为什么很多 C 项目最安全的写法是：

c 复制代码

static inline int f(int x) {
    return x + 1;
}

static inline 在 GNU89 和 C99 下行为最接近：每个翻译单元有自己的内部链接版本，需要时生成本地符号，不需要时可完全内联掉。GCC 文档也指出 static inline 是几种语义下表现相似的重要情况。 [gcc.gnu.org], [blahg.josefsipek.net]

5. `inline` 并入 C99 遇到过阻力吗？

如果说"阻力"指标准委员会内部是否有激烈反对，这个公开资料里不太容易下结论；但如果说工程实践上的阻力 ，答案是：有，而且主要来自既有 GNU C 语义与 C99 语义不兼容。

GCC 4.2 文档说得很直接：inline 已经进入 ISO C99，但当时 GCC 实现与 ISO C99 要求存在"substantial differences"，并说明 GCC 4.3 才会完整支持 C99 inline。

GCC 4.3 移植文档也把 extern inline 的语义变化列为 C 语言移植问题，因为旧代码在 C99 模式下可能突然出现多个定义。 [gcc.gnu.org] [gnu.org]

这种阻力主要表现在三方面：

5.1 既有代码已经依赖 GNU89 语义

很多库和系统头文件早就用了 GNU 风格：

c 复制代码

extern inline int f(...) { ... }

在 GNU89 下，这表示"只给编译器内联用，不输出全局符号"。但在 C99 下，它可能输出外部定义。于是多个 .c 文件包含同一个头文件时，就可能链接时报：

text 复制代码

multiple definition of `f'

GCC 4.3 porting 文档专门说，如果想要旧 GNU 行为，可以使用 extern inline __attribute__((__gnu_inline__)) 或 -fgnu89-inline。 [gnu.org]

5.2 GCC 自己也经历了过渡期

GCC 4.2 时代会警告：C99 inline functions are not supported; using GNU89，并提示用 -fgnu89-inline 或 gnu_inline 属性关闭警告。GCC 帮助邮件列表里也解释：4.3 之前的 GCC 在 C99 模式下仍使用 GNU inline 语义，4.3 才改为真正的 C99 语义，因此 4.2 的警告是为了提前提醒用户后续可能破坏兼容。 [spinics.net], [gcc.gnu.org]

5.3 系统项目需要适配

FreeBSD 邮件列表里有人总结过 GCC 版本差异：GCC 4.3+ 在 -std=gnu99 / -std=c99 下使用 C99 规则；-std=gnu89 下使用 GNU 规则；旧版本则有不同程度的不完整支持或警告。邮件还建议，static inline 是 GNU 和 C99 都比较一致的写法。 [lists.freebsd.org]

所以，C99 并入 inline 的阻力不一定是"反对这个功能"，而是：

标准化后的语义与 GNU C 既有事实标准不一致，导致大量旧代码、头文件、库在切换标准模式时可能出现 undefined reference 或 multiple definition。

这也是为什么 GCC 保留了 -fgnu89-inline 和 gnu_inline 属性，给旧代码一个逃生通道。 [gcc.gnu.org], [gnu.org]

6. 一条简明时间线

C89/C90 ：没有 inline，inline 不是标准 C 关键字。GCC 的 -ansi / -std=c90 会关闭与 ISO C90 冲突的特性，文档也提到 C90 模式下会禁用 inline 关键字，但 __inline__ 这样的 GNU 替代关键字仍可用。 [splichal.eu], [gcc.gnu.org]
GNU C / GNU89 阶段 ：GCC 作为扩展支持 inline，形成 GNU89 传统语义。GCC 文档至今仍把 -std=gnu89 / -fgnu89-inline 作为传统 GNU inline 语义入口。 [gcc.gnu.org], [gnu.org]
1999：C99 发布 ：inline 成为标准 C 的函数说明符。C99 正式编号是 ISO/IEC 9899:1999，inline 是 C99 新增特性之一。 [gcc.gnu.org], [en.cppreference.com]
GCC 4.2 前后 ：GCC 文档说明 C99 inline 与 GCC 实现仍有显著差异，并预告 GCC 4.3 会完整支持 C99 inline。 [gcc.gnu.org]
GCC 4.3，2008-03-05 ：在 C99 / GNU99 模式下采用 C99 inline 语义，同时保留 -std=gnu89、-fgnu89-inline、gnu_inline 来使用旧 GNU 语义。 [gnu.org], [gnu.org]
GCC 5 起默认标准变化 ：GCC 5 默认从 GNU89 变为 GNU11，因此默认 inline 语义也随之从 GNU89 风格变成 C99 风格，这又引发了一波移植问题。GCC 5 porting 文档明确指出默认标准变成 GNU11，并提醒 inline 语义不同。 [gnu.org]

7. 实践建议

如果你写 C 头文件，最推荐：

c 复制代码

static inline int add1(int x) {
    return x + 1;
}

这在 GNU89、C99、C11、C17、C23 下都最少惊喜。

如果你维护老 GNU C 代码，并且依赖 GNU89 的 extern inline 语义，可以：

bash 复制代码

gcc -std=gnu99 -fgnu89-inline ...

或者：

c 复制代码

extern inline __attribute__((gnu_inline))
int f(int x) {
    return x + 1;
}

GCC 官方文档也明确提供了这些兼容方式。 [gcc.gnu.org], [gnu.org]

核心结论 ：inline 最初是为了解决"宏快但不安全，函数安全但可能慢"的矛盾；GNU C 早于 C99 就有自己的 inline 扩展；C99 标准化了它，但选择了一套与 GNU89 不同的外部定义规则，导致 GCC 和大量既有代码经历了较长过渡期。最稳的工程写法通常是 static inline。

三、GCC4.2文档作者怎么知道gnu inline和ISO c99的实现有差别的

复制代码

在第二节
（二、gnu89在什么时候支持inline的，inline的发展历史，inline出现的原因，inline并入c99遇到的阻力）
第1小节第二段，
提到说 "gcc 4.2 文档讲述到" ISO C99 的 inline 与 GCC 当时实现存在重大差异"

"GCC 4.2 文档说 C99 inline 与当前实现有差异"这件事，不是在说他们已经有了某个神秘的"ISO C99 实现"可对比，而是在拿 GCC 当时实现和 ISO C99 标准文本作对比。

1. "什么时候讲的这些差异？"

我前面说的那句话主要来自 GCC 4.2.4 manual 的 Inline 章节。那一页明确写道：

Inline functions are included in the ISO C99 standard, but there are currently substantial differences between what GCC implements and what the ISO C99 standard requires. GCC will fully support C99 inline functions in version 4.3.

也就是：ISO C99 已经有 inline，但 GCC 4.2 当前实现和 C99 要求有显著差异；GCC 4.3 会完整支持 C99 inline；旧 GNU 语义仍可用 -std=gnu89、-fgnu89-inline 或 gnu_inline 属性。 [gcc.gnu.org]

时间上要稍微区分：

GCC 4.2.0 发布于 2007-05-13 ；4.2.1、4.2.2、4.2.3、4.2.4 分别在 2007-07-18、2007-10-07、2008-02-01、2008-05-19 发布。 [gcc.gnu.org]
GCC 4.2 release notes 在 "C family" 里已经预告：下一版 GCC 4.3 中，-std=c99 或 -std=gnu99 会让 GCC 按 C99 标准处理 inline；为了准备这个变化，GCC 4.2 会在 c99/gnu99 模式下对 non-static inline 发警告。 [gcc.gnu.org]
所以更准确的说法是：这个说法至少在 GCC 4.2 release series 文档阶段，也就是 2007 年 GCC 4.2 发布周期内已经公开出现；GCC 4.2.4 手册中仍保留了这段说明。 [gcc.gnu.org], [gcc.gnu.org]

有个小细节：GCC 4.2.4 是 2008-05-19 发布，而 GCC 4.3.0 是 2008-03-05 发布 ，所以你看到 4.2.4 手册里还写 "GCC will fully support C99 inline functions in version 4.3"，这看起来像"未来时"，其实是因为 4.2 分支文档沿用了 4.2 系列的说明口径 。GCC 4.2 release series 页面列出了 4.2.4 在 2008-05-19，而 4.3.0 在官方 release timeline 中是 2008-03-05。 [gcc.gnu.org], [gcc.gnu.org]

2. "文档作者怎么知道 ISO C99 的实现？"

这里要纠正一个表述：不是"ISO C99 的实现"，而是"ISO C99 的标准要求"。

ISO C99 是标准文本，即 ISO/IEC 9899:1999 。inline 的规范在 C99 的 6.7.4 function specifiers 部分；公开文章也经常指出 C99 inline 的规则来自 6.7.4。 [Inline Fun...tions In C]

所以 GCC 文档作者/维护者知道差异，不是因为他们看到另一个"官方 C99 编译器实现"，而是因为他们读了标准，并把标准语义和 GCC 旧有 GNU C 语义做对比。

对比点主要是这个：

GNU89 语义

c 复制代码

inline int f(int x) { return x + 1; }

通常会产生一个外部定义。

c 复制代码

extern inline int f(int x) { return x + 1; }

只用于内联，不产生独立外部定义。GCC 4.2 手册正是这样描述 extern inline：定义只用于内联，绝不单独编译成函数体，取地址也变成外部引用。 [gcc.gnu.org]

C99 语义

c 复制代码

inline int f(int x) { return x + 1; }

这是 inline definition，本身不提供 external definition ；程序中最好还要有一个外部定义供未内联调用使用。公开的 C99 inline 规则说明也明确说：只有 inline 而没有 extern 的 inline definition 不产生 standalone object code。 [Inline Fun...tions In C]

c 复制代码

extern inline int f(int x) { return x + 1; }

在 C99 语义下反而会提供外部定义，和 GNU89 的直觉相反。GCC 4.3 之后的文档也明确说 GCC 有三套 inline 语义：GNU89、C99/GNU99、C++。 [gcc.gnu.org]

所以他们"知道"的其实是：

C99 标准要求的 linkage / external definition 规则，和 GCC 传统 GNU C inline 规则不一样。

不是"知道某个 ISO C99 编译器怎么实现"。

3. GCC 4.2 文档为什么能预告 GCC 4.3？

因为这不是普通用户的猜测，而是 GCC 项目自己的 release planning / implementation transition。

GCC 4.2 release notes 说得很明确：GCC 4.3 中，-std=c99 或 -std=gnu99 会按 C99 标准处理 inline；GCC 4.2 先增加警告，并提供 gnu_inline 属性和 -fgnu89-inline 作为兼容手段。 [gcc.gnu.org]

到了 GCC 4.3 的手册，文本就改成了现在时：

GCC implements three different semantics of declaring a function inline. One is available with -std=gnu89 or -fgnu89-inline or gnu_inline，another when -std=c99 or -std=gnu99，third for C++。

也就是说，GCC 4.3 文档确认：4.3 开始同时支持 GNU89 inline、C99 inline、C++ inline 三种语义。 [gcc.gnu.org]

4. "作者"是谁？能不能定位到具体个人？

严格说，GCC manual 通常不是单一作者文章，而是 FSF/GCC 开发者社区维护的文档 。那段文字未必能直接归因到某一个人。GCC 4.2 release page 也把贡献归于 GCC developers/community，并建议通过 GCC mailing list 反馈文档和开发问题。 [gcc.gnu.org]

不过，从背景上看，GCC 的 C 前端维护者、C 标准参与者当然很清楚这些问题。比如 Joseph Myers 的个人页面说明他从 2001 到 2008 年是英国 C 标准小组成员，参与 ISO/IEC 9899 相关问题，并且是 GCC C front end 的 co-maintainer。

但要小心：这只能说明 GCC 社区里确实有懂 C 标准并参与标准工作的维护者；不能直接证明这段手册文字就是他写的。 [polyomino.org.uk]

5. 最简结论

你可以这样理解：

GCC 4.2 文档说的"差异"，是指 GCC 旧 GNU inline 语义 和 ISO C99 标准 6.7.4 对 inline/external definition 的要求 有差异。

它不是拿"某个 ISO 官方实现"作比较，而是拿标准文本作比较。

GCC 4.2 阶段已经预告 GCC 4.3 会切换到 C99 语义，并提前加警告、加 -fgnu89-inline / gnu_inline 作为兼容方案。 [gcc.gnu.org], [gcc.gnu.org], [gcc.gnu.org]

文档作者不是"知道 ISO C99 的实现"，而是知道 ISO C99 的规范；GCC 4.3 的实现计划正是为了让 GCC 的 c99/gnu99 模式符合这个规范。

gnu89和c99中的inline关键字的关系和差异

一、

GCC 的 inline 扩展：体现在"符号发射规则"上

GNU89 的 inline 语义（GCC 自创）

C99 的 inline 语义（标准化后改了规则）

static inline 为什么两者都兼容？

总结一句话

二、gnu89在什么时候支持inline的，inline的发展历史，inline出现的原因，inline并入c99遇到的阻力

1. GNU89 支持 inline的时间

2. inline优点

3. C99 把 inline 纳入标准的原因

4. GNU89 inline 和 C99 inline 区别

GNU89 传统语义大致是：

C99 语义大致是：

5. inline 并入 C99 遇到过阻力吗？

5.1 既有代码已经依赖 GNU89 语义

5.2 GCC 自己也经历了过渡期

5.3 系统项目需要适配

6. 一条简明时间线

7. 实践建议

三、GCC4.2文档作者怎么知道gnu inline和ISO c99的实现有差别的

1. "什么时候讲的这些差异？"

2. "文档作者怎么知道 ISO C99 的实现？"

GNU89 语义

C99 语义

3. GCC 4.2 文档为什么能预告 GCC 4.3？

4. "作者"是谁？能不能定位到具体个人？

5. 最简结论

四、

GCC 的 `inline` 扩展：体现在"符号发射规则"上

GNU89 的 `inline` 语义（GCC 自创）

C99 的 `inline` 语义（标准化后改了规则）

`static inline` 为什么两者都兼容？

1. GNU89 支持 `inline`的时间

2. `inline`优点

3. C99 把 `inline` 纳入标准的原因

4. GNU89 `inline` 和 C99 `inline` 区别

5. `inline` 并入 C99 遇到过阻力吗？