制作普通 int 64 位会破坏很多合理的代码吗？

Question

直到最近，我还认为大多数系统实现者/供应商即使在 64 位机器上也保留普通 int 32 位的决定是一种权宜之计。对于现代 C99 固定大小类型（int32_t 和 uint32_t 等），需要有一个每种大小为 8、16、32 和 64 的标准整数类型大部分都消失了，而且 int 似乎也可以做成 64 位。

然而，C 中普通 int 大小的最大实际后果来自于 C 本质上不支持小于 int 类型的算术。特别是，如果 int 大于 32 位，则对 uint32_t 值进行任何算术运算的结果都具有 signed int 类型，这是相当令人不安的。

这是在实际实现中将 int 永久固定为 32 位的好理由吗？我倾向于说“是”。在我看来，uint32_t 的大量使用可能会在 int 大于 32 位时中断。即使应用一元减号或按位求补运算符也会变得危险，除非您强制转换回 uint32_t。

当然，同样的问题也适用于当前实现中的 uint16_t 和 uint8_t，但每个人似乎都意识到并习惯于将它们视为“小于 int””类型。

Answer 1

正如你所说，我认为晋升规则确实是杀手锏。然后，uint32_t 将提升为 int，突然之间，您就已经签署了几乎每个人都期望无符号的算术。

这主要隐藏在您只进行算术并分配回 uint32_t 的地方。但在与常量进行比较的地方，这可能是致命的。我不知道依赖于此类比较而不进行显式转换的代码是否合理。像 (uint32_t)1 这样的常量转换可能会变得非常乏味。我个人至少总是使用后缀 U 来表示我想要无符号的常量，但这已经没有我想要的那么可读了。

另请记住，不保证 uint32_t 等存在。甚至连uint8_t都没有。其执行是 POSIX 的扩展。所以从这个意义上说，C 作为一门语言还远远无法实现这一目标。

Answer 2

“合理的代码”……

嗯……关于开发的事情是，你编写并修复它，然后它就可以工作了……然后你就停下来了！

也许您已经被烧伤过很多次，所以您可以很好地保持在某些功能的安全范围内，也许您没有以那种特定方式被烧伤，所以您没有意识到自己正在依赖于可能会发生改变的东西。

或者甚至你依赖于一个错误。

在旧的 Mac 68000 编译器上，int 为 16 位，long 为 32。但即使如此，大多数现有的 C 代码也假定 int 为 32，因此您在新闻组中找到的典型代码将无法工作。 （哦，Mac 没有 printf，但我离题了。）

所以，我想说的是，是的，如果你改变任何东西，那么有些东西就会被破坏。

Answer 3

使用现代 C99 固定大小类型
（int32_t和uint32_t等）需要
存在一个标准整数
每种尺寸的类型 8、16、32 和 64
大部分消失了，

C99 有固定大小的 typeDEF，而不是固定大小的类型。原生 C 整数类型仍然是 char、short、int、long 和 long long< /代码>。它们仍然具有相关性。

ILP64 的问题在于它在 C 类型和 C99 类型定义之间存在很大的不匹配。

• int8_t = char
• int16_t = Short
• int32_t = 非标准类型
• int64_t = int、long 或 long long

来自 64 位编程模型：为什么选择 LP64？：

不幸的是，ILP64 模型确实
没有提供自然的描述方式
32 位数据类型，并且必须求助于
非便携式结构，例如
__int32 来描述此类类型。这很可能会导致实际问题
在生成可以运行的代码时
32 位和 64 位平台均无需
#ifdef 结构。大量的港口已经成为可能
无需代码即可转换为 LP64 型号
做出这样的改变，同时
维持已进行的投资
数据集，即使在
未输入信息
应用程序外部可见。

Answer 4

DEC Alpha 和 OSF/1 Unix 是 Unix 的第一个 64 位版本之一，它使用 64 位整数 - ILP64 架构（意味着 int、long 和指针都是 64 位量）。这引起了很多问题。

我没有看到提到的一个问题 - 这就是为什么我在这么长时间后才回答 - 是如果你有一个 64 位 int，你使用什么大小的 short ？ 16 位（经典的、不改变任何内容的方法）和 32 位（激进的“好吧，short 的长度应该是 int”方法的一半）都将呈现一些问题。

使用 C99 和 标头，您可以编码为固定大小的整数 - 如果您选择忽略 36 位机器或 60 位整数（至少是准合法的）。然而，大多数代码并不是使用这些类型编写的，并且代码中通常存在根深蒂固且很大程度上隐藏的（但从根本上有缺陷的）假设，如果模型偏离现有的变体，这些假设就会被破坏。

请注意 Microsoft 针对 64 位 Windows 的超保守 LLP64 模型。之所以选择它，是因为如果更改 32 位模型，太多的旧代码会被破坏。但是，由于差异，已移植到 ILP64 或 LP64 架构的代码不会立即移植到 LLP64。阴谋论者可能会说，这是故意选择的，目的是让为 64 位 Unix 编写的代码更难移植到 64 位 Windows。实际上，我怀疑这是否不仅仅是一个令人高兴的（对微软来说）副作用； 32 位 Windows 代码也必须进行大量修改才能使用 LP64 模型。

Answer 5

如果 int 是 64 位，有一种代码习惯用法会被破坏，而且我经常看到它，我认为它可以被称为合理：

• 通过测试 if ((val & 0x80000000) != 来检查值是否为负数0)

这常见于检查错误代码。许多错误代码标准（如 Window 的 HRESULT）使用位 31 来表示错误。代码有时会通过测试位 31 或有时通过检查错误是否为负数来检查该错误。

Microsoft 用于测试 HRESULT 的宏使用这两种方法 - 而且我确信有大量代码在不使用 SDK 宏的情况下执行类似操作。如果 MS 迁移到 ILP64，这将是导致移植问题的一个领域，而 LLP64 模型（或 LP64 模型）可以完全避免这些问题。

注意：如果您不熟悉“ILP64”等术语，请参阅答案末尾的迷你术语表。

我很确定有很多代码（不一定是 Windows-定向）使用 plain-old-int 来保存错误代码，假设这些 int 的大小为 32 位。我敢打赌，有很多具有该错误状态方案的代码也使用两种检查（<0 和设置的位 31），如果移动到 ILP64 平台，这些代码将会中断。如果错误代码经过精心构造，以便进行符号扩展，那么这些检查可以继续正常工作，但同样，我见过的许多此类系统通过或操作一堆位字段来构造错误值。

无论如何，我认为这不是一个无法解决的问题，但我确实认为这是一种相当常见的编码实践，如果迁移到 ILP64 平台，将导致大量代码需要修复。

请注意，我也不认为这是 Microsoft 选择 LLP64 模型的最重要原因之一（我认为该决定很大程度上是由 32 位和 64 位进程之间的二进制数据兼容性驱动的，如 在 MSDN 和 雷蒙德·陈的博客）。

---

64 位平台编程模型术语的迷你词汇表：

• ILP64：int、long，指针为 64 位
• LP64：long 和指针是 64 位，int 是 32 位（许多（大多数？）Unix 平台使用）
• LLP64：long long 和指针是 64 位-bits、int 和 long 仍为 32 位（在 Win64 上使用）

有关 64 位编程模型的详细信息，请参阅 "64 位编程模型：为什么选择 LP64？"

Answer 6

虽然我个人不会编写这样的代码，但我敢打赌它存在于不止一个地方......当然，如果您更改 int 的大小，它就会中断。

int i, x = getInput();
for (i = 0; i < 32; i++)
{
    if (x & (1 << i))
    {
        //Do something
    }
}

Answer 7

嗯，这个故事并不是什么新鲜事。我认为“大多数计算机”指的是台式计算机。 int 已经从 16 位转换为 32 位。有什么可以表明这次不会发生同样的进展吗？

Answer 8

不是特别。 int 在某些 64 位架构（不是 x64）上是 64 位。

该标准实际上并不保证您获得 32 位整数，只是 (u)int32_t 可以容纳一个。

现在，如果您依赖 int 与 ptrdiff_t 大小相同，您可能会被破坏。

请记住，C 语言甚至不保证机器是二进制机器。