其余指导原则将重点说明将应用程序转换为完全 64 位程序时遇到的常见问题。
许多派生类型已进行了更改,以便在 64 位应用程序环境中表示 64 位值。此更改不会影响 32 位应用程序;但是,使用或导出这些类型所描述的数据的任何 64 位应用程序均需要重新求值。关于这一点的一个示例是直接处理 utmp(4) 或 utmpx(4) 文件的应用程序。要在 64 位应用程序环境中正确操作,请勿尝试直接访问这些文件, 而应使用 getutxent(3C) 及相关的函数系列。
需要注意的一个问题是,一个区域中的类型更改可能会导致另一个区域中进行意外的 64 位转换。例如,如果某个函数以前返回 int 而现在返回 ssize_t,则需要检查所有调用方。
定义为 long 的变量在 ILP32 数据类型模型中为 32 位,在 LP64 数据类型模型中为 64 位。如有可能,通过重新定义变量并使用可移植性更强的派生类型避免出现问题。
与此相关的是,许多派生类型在 LP64 数据类型模型中已更改。例如,在 32 位环境中,pid_t 仍为 long,而在 64 位环境中,pid_t 为 int。
在某些情况下,一个接口存在特定的 32 位和 64 位版本是不可避免的。可以通过在头文件中指定 _LP64 或 _ILP32 功能测试宏区分这些版本。同样,在 32 位和 64 位环境中运行的代码需要利用相应的 #ifdefs,具体取决于编译模式。
当您通过值传递结构并针对 64 位环境编译代码时,若结构足够小,则通过寄存器传递结构而不是将结构作为副本的指针。如果您尝试在 C 代码与手写汇编代码之间传递结构,这会导致问题。
浮点参数的工作方式类似;有些通过值传递的浮点值通过浮点寄存器传递。
在确认代码对 64 位环境是安全的之后,请再次检查代码,以验证算法和数据结构是否仍有意义。数据类型较长,因此数据结构可能占用更多空间。代码的性能也可能变化。出于这些利害关系考虑,您可能需要相应地修改代码。