编写可移植到 32 位和 64 位架构的代码时要考虑的要点答案

【问题标题】：Points to be considered for writing code which is portable to both 32 and 64 bit architectures编写可移植到 32 位和 64 位架构的代码时要考虑的要点
【发布时间】：2011-01-16 06:55:40
【问题描述】：

在编写可在 32 位和 64 位机器上移植的代码时应牢记哪些要点？

对此进行更多思考，我觉得如果您可以就所面临的问题添加您的经验，那会有所帮助。

进一步补充说，我曾经遇到过一个问题，原因是缺少返回指针的函数原型。当我将它移植到 64 位机器上时，代码崩溃了，我很长一段时间都不知道原因，后来意识到所有丢失的原型都假定返回导致问题的 int。

任何这样的例子都会有所帮助。

编辑：添加到社区 wiki。

【问题讨论】：

标签： c portability 32bit-64bit

【解决方案1】：

某些整数类型可能有不同的大小
指针的长度不同
结构填充
对齐

在 Windows 上，只有 x64 上的调用约定，而不是常规 x32 机器上的多个。

当您拥有一些 32 位和一些 64 位组件时，事情会变得更加模糊。在 Windows 上，我最终编写了一个 COM 服务来让他们说话。

【讨论】：

【解决方案2】：

将指针压入堆栈会占用两倍的空间。但是，堆栈大小可能不会在 OS 版本之间发生变化，导致在 32 位中运行良好的代码在编译时会神秘地失败，而在 64 位上运行时保持不变。不要问我怎么知道的。

【讨论】：

我从来没有听说过这个。这真的有影响吗？
仅当编译器不能/不将指针存储在寄存器中时才适用。

【解决方案3】：

sizeof(int) 可能！= sizeof(void*)

对齐。对齐需求可能会发生变化。这可能会暴露错误，您一直在错误处理本应对齐但只是在 32 位（或在不关心的处理器上）意外对齐的东西

如果接收者期待一个指针，不要将 0 传递给可变参数。这在 C++ 中很痛苦，精明的开发人员知道 0 是一个有效的空指针。 C 开发人员通常会使用 NULL，所以你可能没问题

【讨论】：

+1 现在我想知道这种行为是否合规。标准说 NULL 评估为 0。默认情况下不应该将其提升为 (void*) 吗？并不是说您不应该使用 NULL，而是阅读标准，标头编写者也可以将 NULL 定义为 0。open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf 请参阅 6.3.2.3 上的第 3 点。听起来 GCC 是错误的，或者一旦成为当前标准就会出错。
gcc 在我的例子中将 NULL 转换为 nullptr。所以它奏效了。我同意如果 NULL 被定义为 0 那么它不会修复我的错误，在这种情况下我必须明确地说 (void*)0

【解决方案4】：

陷阱：

将指针转换为整数类型是危险的
数据结构大小可以改变
注意标志扩展
不同的 ABI？

我发现一些有用的提示和技巧：

为自己获取一个原生大小的整数类型（来自标头或 typedef 您自己的），并在您有不关心大小的变量时使用它。
尽可能使用显式变量类型（u_int64_t、int_32_t 等）

【讨论】：

【解决方案5】：

编写自动化测试并在两个平台上定期运行。

【讨论】：