C语言标准演化史：从KR到GNU，谁才是正统？

你知道吗？如今最流行的C语言编译器，其实并不完全遵守C语言标准。换句话说，你写的代码，可能根本就不是“标准C”。这听起来有点反常识，但真相是，C语言从诞生那天起，就一直在“内斗”和“博弈”中进化。

这事得从1978年说起。那一年，丹尼斯·里奇和布莱恩·柯林汉出版了《C程序设计语言》，也就是后来被奉为经典的“K&R C”。那时候的C语言，更像一个手工作坊里的工具，灵活、自由，但也乱得够呛。不同编译器各有各的规矩，你写的一段代码，换个机器可能就跑不了。你想啊，这要是放在今天，程序员们不得疯掉？

所以到了1989年，美国国家标准协会（ANSI）终于出手了，推出了第一个官方标准——ANSI C，也就是C89。紧接着，国际标准化组织（ISO）在1990年也发布了几乎一样的C90。从此，C语言有了“普通话”。但问题来了，这个标准并不是所有人都买账。比如微软，它家的Visual C++编译器，就长期对C99的关键特性爱搭不理，像可变长度数组（VLA）这种好东西，微软愣是拖了好多年才慢慢支持。为啥？商业利益和生态博弈呗。

说到C99，那可是C语言现代化的里程碑。1999年发布的标准，带来了内联函数、`long long`类型、复合字面量、指定初始化器……简直是个大礼包。但结果呢？并不是所有编译器都乖乖照做。嵌入式行业挑着用，微软继续装死，反倒是GNU C——那个自由软件运动的产物，跳出来说：“你们标准太保守，我来加料！”

没错，GNU C就是那个“叛逆者”。它跟GCC编译器深度绑定，在标准C之外搞了一大堆扩展：零长度数组、语句表达式、`typeof`关键字、`__attribute__`机制……这些玩意儿让Linux内核和嵌入式开发者如获至宝，但也让“可移植性”成了笑话。你用GNU C写的代码，到了Windows上用Visual Studio编译，大概率报错。所以现在很多项目都搞个“双轨制”：用`-std=c99`保证可移植，用默认的`-std=gnu11`榨干性能。

到了2011年，C11标准终于开始重视安全性和多线程了，比如匿名结构体、`_Generic`泛型选择，还有那个让人又爱又恨的边界检查函数。可惜，步子迈得不大，主要是修修补补。2017年的C17更是只打了补丁，没加新特性。C语言的进化，从当年的大刀阔斧，变成了现在的谨小慎微。

但有意思的是，GNU C依然在野蛮生长。它那些扩展，比如`__builtin_expect`（用来告诉编译器哪个分支更可能执行），标准C里根本没有，但性能优化上就是好用。你说你是选可移植性，还是选性能？这就像选苹果还是安卓，没有绝对的对错，只有适合不适合。

那你可能会问：未来呢？C语言是不是要完蛋了？别担心，它死不了。你看那些嵌入式芯片、物联网设备、操作系统内核，哪个不是C语言的地盘？只是它的进化会更保守，更注重兼容性。毕竟，C语言背负着几十年的历史包袱，不能像C++那样动不动就推倒重来。而且，GNU C和标准C的“双轨制”很可能长期并存，就像现实世界里，方言和普通话各有用武之地。

说白了，C语言标准的演化史，就是一部程序员、厂商、开源社区之间的权力博弈史。没有哪个标准是“最好”的，只有“最合适”的。如果你刚入门，老老实实学C89/C99的基础语法；如果你要写Linux内核，那就得把GNU C的扩展摸透；如果你关心安全，C11/C17的边界检查函数值得研究。

这事你怎么看？你平时写代码，是用标准C还是GNU扩展？在评论区聊聊，说不定能帮到不少正在纠结的同行。如果觉得有用，转给那个总在“可移植性和性能”之间纠结的朋友吧。