在现有的 32 位代码中添加 64 位支持，难吗？答案

【问题标题】：Adding 64 bit support to existing 32 bit code, is it difficult?在现有的 32 位代码中添加 64 位支持，难吗？
【发布时间】：2011-05-03 22:54:49
【问题描述】：

我针对不同的 32 位平台构建了一个库。现在，必须支持 64 位架构。扩展现有 32 位代码以支持 64 位架构的最通用策略是什么？我应该使用#ifdef 还是其他什么？

【问题讨论】：

【解决方案1】：

所涉及的工作量将完全取决于原始代码的编写程度。在最好的情况下，除了重新编译之外，不会涉及任何工作。在最坏的情况下，您将不得不花费大量时间使您的代码“64 位干净”。

典型问题有：

【讨论】：

+1 只是一些补充：整数参数的一个讨厌的例子是 va_arg 函数：所有对应于... 的窄整数类型将被提升为int。然后，使用具有正确语义的整数typeofs 的代码，例如size_t、uintptr_t、ptrdiff_t、uint64_t，通常只会编译和运行。到处都滥用int 作为循环变量的代码，char 算术忘记了这可能是有符号的还是无符号的，诸如此类的东西正在寻找麻烦。通过不同的编译器运行您的代码并打开所有警告，clang 是对gcc 的一个很好的补充
@Jens：感谢额外的 cmets - 关于使用多个编译器构建和测试的要点非常好。

【解决方案2】：

不依赖机器字长的假设？始终使用 sizeof、stdint.h 等。除非您依赖于不同架构的不同库调用，否则应该不需要 #ifdefs。

【讨论】：

【解决方案3】：

最简单的策略是使用 64 位设置构建您所拥有的内容并对其进行测试。有些代码根本不需要更改。其他代码，通常对整数/指针的大小有错误的假设，会更加脆弱，需要修改为不依赖于架构。

包含二进制记录的二进制文件通常会导致最多的问题。在向 64 位构建过渡的过程中，整数从 32 位增长到 64 位的环境中尤其如此。这主要是因为整数以当前（32 位）长度写入文件，并在 int 为 64 位的 64 位构建中使用不正确的长度读取。

【讨论】：

这当然取决于编译器，但我使用的所有 64 位 C 编译器（gcc、clang），将 int 保留为 32 位，将 long 设为 64 位。
@JeremyP：这取决于平台数据模型 (en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models) 而不是编译器。例如，在 Win64 上，int 和 long 都保持 32 位，而 long long 是 64 位，因此整数模型与 Win32 相同，但指针变为 64 位，因此代码尝试使用 int 或long 保存指针值将失败 - 在需要时更改为 intptr_t。