其他注意事项

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

长度增加的派生类型

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

附录 A，派生类型更改中包括了更改的派生类型的列表。

检查更改的副作用

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

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

由于类型 long 在 ILP32 模型中为 32 位，在 LP64 模型中为 64 位，因此可能会出现以前定义为 long 类型的数据既不恰当又不必要的情况。在这种情况下，请尽可能使用可移植性更强的派生类型。

与此相关的是，由于上述原因，许多派生类型在 LP64 数据类型模型中可能已更改。例如，pid_t 在 32 位环境中仍为 long 类型，但是在 64 位环境中，pid_t 则为 int 类型。有关针对 LP64 编译环境修改的派生类型的列表，请参见附录 A，派生类型更改。

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

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

算法更改

在确认代码对 64 位环境是安全的之后，请再次检查代码，以验证算法和数据结构是否仍有意义。由于数据类型变大，因此数据结构可能会使用更多空间。代码的性能也可能变化。考虑到以上几点，您可能需要相应地修改代码。