7.4 其他考虑事项

其余指导原则将重点说明将应用程序转换为完全 64 位程序时遇到的常见问题。

7.4.1 长度增长的派生类型

许多派生类型已进行了更改，以便在 64 位应用程序环境中表示 64 位值。此更改不会影响 32 位应用程序；但是，使用或导出这些类型所描述的数据的任何 64 位应用程序均需要重新求值。关于这一点的一个示例是直接处理 utmp(4) 或 utmpx(4) 文件的应用程序。要在 64 位应用程序环境中正确操作，请勿尝试直接访问这些文件， 而应使用 getutxent(3C) 及相关的函数系列。

7.4.2 检查更改的副作用

需要注意的一个问题是，一个区域中的类型更改可能会导致另一个区域中进行意外的 64 位转换。例如，如果某个函数以前返回 int 而现在返回 ssize_t，则需要检查所有调用方。

7.4.3 检查直接使用 long 是否仍有意义

定义为 long 的变量在 ILP32 数据类型模型中为 32 位，在 LP64 数据类型模型中为 64 位。如有可能，通过重新定义变量并使用可移植性更强的派生类型避免出现问题。

与此相关的是，许多派生类型在 LP64 数据类型模型中已更改。例如，在 32 位环境中 pid_t 仍为 long，而在 64 位环境中，pid_t 为 int。

7.4.4 对显式 32 位与 64 位原型使用 #ifdef

在某些情况下，一个接口存在特定的 32 位和 64 位版本是不可避免的。可以通过在头文件中指定 _LP64 或 _ILP32 功能测试宏区分这些版本。同样，在 32 位和 64 位环境中运行的代码需要利用相应的 #ifdefs，具体取决于编译模式。

7.4.5 调用转换更改

当您通过值传递结构并针对 64 位环境编译代码时，若结构足够小，则通过寄存器传递结构而不是将结构作为副本的指针。如果您尝试在 C 代码与手写汇编代码之间传递结构，这会导致问题。

浮点参数的工作方式类似；有些通过值传递的浮点值通过浮点寄存器传递。

7.4.6 算法更改

在确认代码对 64 位环境是安全的之后，请再次检查代码，以验证算法和数据结构是否仍有意义。数据类型较长，因此数据结构可能占用更多空间。代码的性能也可能变化。出于这些利害关系考虑，您可能需要相应地修改代码。