LP64、LLP64和IL32过渡

Question

在20世纪80年代从16位到32位的转变中，int 的大小要么是16位，要么是32位。使用当前的64位过渡命名规则，我了解到ILP32和LP32机器的分布相当均匀。当时人们普遍认为，在任何给定的体系结构中，int 都将遵循寄存器或指针宽度，并且 long 仍然保持32位。

快进25年，我看到LP64已经非常主流，但直到我在2007年发现桌面Linux之前，我总是期望IP64成为下一个逻辑步骤。

• 这是否是64位的预期演进（指LP64）？
• “char ≤ short ≤ int ≤ long”关系如何适应这种固定整数类型的新兴方案，以便我们在离开不同平台时能够轻松移植代码？
• 这些过渡计划与各平台上使用（您选择的大小写）WORD/DWORD有何关系？
• Windows某些领域仍包含16位的INT形式。 Windows会走出LLP64吗，还是为时已晚？
• 为什么这次选择留下int，而不是在32位转换期间留下它？

- Matt Joiner

---

如果将long固定为32位，那么int就永远无法增长，因为根据定义sizeof(int) <= sizeof(long)。因此，IP64从未被考虑过。 - Ben Voigt

如果是这样，Ben Voigt，请提供与此关系的C语言官方定义链接？ - Matt Joiner

@MattJoiner，来自K＆R的《C程序设计语言第二版》2.2节：“每个编译器都可以自由选择适合其硬件的大小，仅受到short和int至少为16位，long至少为32位以及short不超过int，int不超过long的限制。”这意味着sizeof(int) <= sizeof(long)。 - wovano

在C99标准（草案）中，它的表述略有不同：“对于任何两个带有相同符号和不同整数转换等级的整数类型，具有较小整数转换等级的类型的值范围是另一种类型值范围的子范围_”，并且在文档中进一步指出：“long long int的等级应大于long int的等级，long int的等级应大于int的等级，int的等级应大于short int的等级，short int的等级应大于signed char的等级_”。 - wovano

Answer 1

我认为在整个x64过渡中，Windows是一个奇怪的存在。但是抛开这一点，C或C ++从未定义整数类型为固定长度。如果您这样看待它，我觉得整个int / long / pointer的事情很容易理解：

- int：大多数情况下长度为32位（Linux，Mac和Windows） - long：在Mac和Linux上为64位，在Windows上为32位 - long long：在Mac，Linux和Windows x64上都是64位 - （u）intptr_t：指针的确切长度（32位系统上为32位，64位系统上为64位）

WORD和DWORD很丑，应该避免使用。如果API强制使用它们，请在处理指针时将DWORD替换为DWORD_PTR。我认为一开始在那里使用(D)WORD是不正确的。 我不认为Windows会改变它的决定，因为已经有太多麻烦了。

为什么int被抛弃了？金星为什么会逆转方向旋转？第一个问题的答案可以在这里找到（我认为），而第二个问题则更加复杂 ;)

- rubenvb

---

@Billy：我想你错过了下一句话，请不要替我说话。 - rubenvb

Billy是完全正确的，当您调用类型为DWORD的API时应该使用DWORD。 - Ben Voigt

永远没有创建DWORD类型变量的理由，就像没有创建gint类型变量的理由一样（只是为了平等对待Windows和Linux的白痴行为）。Windows API函数的原型将确保你的合理类型的变量被正确推入栈中以进行函数调用。 - R.. GitHub STOP HELPING ICE

显然你从来没有编写过Windows代码。Windows API不仅需要传递参数，还有来自回调函数如WndProc的入参以及API的返回值。唯一可靠的方式将WndProc参数不变地传递给DefaultWndProc是使用正确的Windows定义类型(LPARAM和WPARAM)。如果使用其他类型，你的代码在从Win16到Win32再从Win32到Win64转换时会出错。 - Ben Voigt

我自己总是使用API类型，但只限于接口边界，并且仅在从我的自定义类型转换非常复杂时才使用。如果您需要稍后再次与同一API重用值（例如句柄），那么任意强制转换为自己的类型是愚蠢和危险的。 - Matt Joiner

Answer 2

与其说将 int 称为"被落下的类型"，我认为你应该考虑不能放弃任何可能需要的大小类型。我想编译器可以用一些内部的扩展类型 __int32_t 定义 int32_t，但由于 C99 仍未得到广泛支持，在构建系统无法在标准类型中找到 32 位类型时，应用程序必须解决缺少 int32_t 定义的主要问题。而拥有一个 32 位类型是必不可少的，无论您的本机字长是多少（例如，它是 Unicode 码点值的唯一正确类型）。

出于同样的原因，使 short 成为 32 位，int 成为 64 位也是不可行的：16 位类型对于许多事情都是必需的，音频处理是首先想到的。 （更不用说 Windows/Java 对丑陋的 UTF-16 偏爱了..）

实际上，我认为 16 到 32 位和 32 到 64 位的转换根本不可比。放弃 16 位是放弃了大多数日常生活中遇到的数字无法适合基本类型的系统，需要使用 "far" 指针等技巧来处理非平凡数据集。另一方面，大多数应用程序对于 64 位类型的需求很小。大型货币数字、多媒体文件大小/偏移量、磁盘位置、高端数据库、内存映射访问大型文件等是一些特殊应用程序，但没有理由认为文字处理器需要数十亿个字符，或者网页需要数十亿个 HTML 元素。这些只是数字大小与物理世界、人类思维等现实之间的根本差异。

- R.. GitHub STOP HELPING ICE

---

我认为从嵌入式和Windows的角度来看，你可以把C99称为“支持不广泛”，但是对于我自己每天使用它来说，这种说法感觉很奇怪。我认为您在普通类型和stdint类型之间缺少区分，我认为没有仅仅为了保留32位整数而被遗弃的类型。 - Matt Joiner

当做出“决定”时，除了现代自由的Unix系统外，缺少stdint.h/inttypes.h在实践中是一个重要的考虑因素。你认为为什么configure（autoconf等）总是对所有标准类型的大小进行无用的预构建检查？ - R.. GitHub STOP HELPING ICE

更不用说64位Unix在非x86平台上就早于C99了。 - Yuhong Bao