语言为何没有将 int 类型的大小标准化？

C 语言诞生于 1972 年彼时计算机体系结构千差万别。一个广为人知的原因是C 被设计为一种高度可移植的语言能够轻松适配各种硬件平台。在那个年代不同 CPU 的数据总线宽度和寄存器位宽差异极大——例如 PDP-11 是 16 位机器而 CDC-6600 则使用 60 位字长。因此C 语言的设计理念是让 int 类型尽可能匹配目标平台的“原生”整数类型即其位宽通常等于 CPU 寄存器的大小并能直接映射到对应的机器指令。今天在 RISC 架构中我们仍能看到类似做法所有的算术和逻辑运算都只在原生整数字长上进行。如何解决这个问题最简单的方案正是 C 语言当初采取的策略。在 C 中基本数据类型的大小并非固定不变而是彼此之间保持相对关系例如 short ≤ int ≤ long。然而这种灵活性也带来了问题。以 8 位 CPU 为例int 通常是 16 位但 CPU 的原生运算单元只有 8 位。由于 C 语言规定“整型提升”integer promotion——即所有小于 int 的整数运算都会先提升为 int 类型再执行——这会导致性能严重下降。这一问题在 C99 标准中得到了改善通过引入 头文件开发者可以使用具有明确位宽的类型如 int32_t、uint16_t 等从而避免平台依赖性。那么C 语言中整型大小不固定到底会带来什么麻烦一个典型例子是void* pPtr;int Pointer (int)pPtr; // 将指针转为 int...pPtr (void*)Pointer; // 再转回指针这段代码在 32 位系统上运行良好但在 64 位系统上就会出错。更糟的是如果开发者改用 long 类型本以为它比 int 更大在 Windows x64 上依然会失败。问题根源在于 C 语言中 int 和 long 的大小在 32 位与 64 位平台之间并不一致 。具体来说这就导致了一个严重隐患假设某程序在 Linux 上开发开发者使用 long 来处理超过 32 位的数据程序编译运行正常但一旦移植到 Windows 64 位平台long 变成 32 位程序可能在运行时崩溃或产生错误结果。除了 int其他类型在特殊硬件上也会引发问题。例如许多数字信号处理器DSP对 char 类型的处理就很特别。不少 DSP如 TI 的 C2000 和 C5000 系列根本不支持真正的 8 位操作char 实际占 16 位一些更新的 TI DSP 甚至将 char 定义为 32 位。更微妙的是 C 标准规定 sizeof(char) 必须为 1 。在这些 DSP 上这意味着“一个字节”实际上是 16 位或 32 位更有甚者某些平台上 sizeof(int) 也可能等于 1而非我们习惯的 4进一步加剧了跨平台开发的复杂性。类似情况在微控制器领域也很常见。例如 Microchip 的 PIC24 系列其 RAM 指针是 16 位而 ROM程序存储器指针却是 24 位——指针本身都不统一综上所述C 语言当初为追求硬件适配性和效率而放弃固定整型大小虽在历史上有其合理性但也给现代跨平台开发埋下了诸多陷阱。使用 中的固定宽度类型是规避这些问题的最佳实践。