在我看来，未必。和jmp_buf一样，它不是一个不透明类型，也就是说，它被大量的随机结构内联，被其他大量的语言和编译器视为一个特定的表示，并且可能存在于大量的公共接口中，而这些接口不在 libc、linux、甚至发行版维护者的控制之下。
当然，libc 可以适当地使用符号版本化技巧，使其 API 可以适应新的定义，但是，改变一个基本数据类型（像intmax_t）的大小，会在更大的平台生态系统中引发混乱。
如果有人能够证明我是错的，我会很高兴，但据我所知，做出这样的改变需要一个新的目标三元组，并且不允许任何为旧 ABI 构建的二进制文件/库在这个新三元组上运行。当然，你可以这样做，但我并不羡慕任何做了这些工作的发行版。
即使如此，还有 x64 int 的问题：它是非常基本的类型，而且长期以来大小从没变过，无数的应用程序可能对它做了无法察觉的假设。这就是为什么 int 在 x64 上是 32 位的，尽管它“应该”是 64 位的：int 长期以来都是 32 位，以至于将软件升级到新的大小完全无望，尽管它是一个全新的架构和目标三元组。
我也希望我的观点是错的。如果 C 语言只是一种独立的编程语言，那我们就可以毫无顾虑地往前冲。但它实际上不是了，它是一个协议，还是一个糟糕的协议，而我们还必须要用它。
很遗憾，C，你征服了世界，但或许不再拥有往昔的美好。
原文链接：https://gankra.github.io/blah/c-isnt-a-language
