真的能改变intmax_t吗？
在Aria看来，不完全是。就像jmp_buf一样，它不是一个不透明的类型，这意味着它被内联到大量的随机结构中，被认为具有大量其他语言和编译器的特定表示，并且可能是大量公共接口的一部分。而这些接口并不在libc、Linux，甚至不在发行版维护者的控制之下。
当然，libc可以适当地使用符号版本技巧来使其API与新的定义兼容，但改变像 intmax_t这样的基本数据类型的大小，是在一个平台的大生态系统中寻求混乱。
Aria希望被证明自己是错误的，但据她所知，做出这样的改变需要一个新的目标三元组，并且不允许任何为旧ABI构建的二进制/库在这个新三元组上运行。当然有人可以做这些工作，但Aria并不羡慕任何这样做的发行版。
即使如此，面临的还有x64的int问题：这是一个非常基本的类型，而且长期以来一直是这种大小，无数的应用程序可能对它有奇怪的无法察觉的假设。这就是为什么int在x64上是32位的，尽管它应该是64位的：int是32位的时间太长了，以至于完全无望将软件更新到新的大小，尽管它是一个全新的架构和目标三元组。
Aria再次希望自己是错的，但是人们有时犯的错误如此严重，以至于根本无法挽回。如果C语言是一种独立的编程语言？当然可以去做。但它不是，它是一个协议，还是我们必须使用的糟糕的协议。
就算C征服了世界，但也许它再也得不到好东西了。