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 语言当初为追求硬件适配性和效率而放弃固定整型大小，虽在历史上有其合理性，但也给现代跨平台开发埋下了诸多陷阱。使用 中的固定宽度类型，是规避这些问题的最佳实践。