Solaris(64 位)开发者指南

其他注意事项

其余指导原则将重点说明将应用程序转换为完全 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 位环境是安全的之后,请再次检查代码,以验证算法和数据结构是否仍有意义。由于数据类型变大,因此数据结构可能会使用更多空间。代码的性能也可能变化。考虑到以上几点,您可能需要相应地修改代码。