A number of derived types have changed so they represent 64-bit quantities in the 64-bit application environment. This change does not affect 32-bit applications; however, any 64-bit applications that consume or export data described by these types need to be reevaluated for correctness. An example of this is in applications that directly manipulate the utmpx(4) files. For correct operation in the 64-bit application environment, you should not attempt to directly access these files. Instead, you should use the getutxent(3C) and related family of functions.
A list of changed derived types is included in Appendix A, Changes in Derived Types.
One problem to be aware of is that a type change in one area might result in
an unexpected 64-bit conversion in another area. For example, in the case of a function
that previously returned an int
and now returns an ssize_t
,
all the callers need to be checked.
Because a long
is 32 bits in the ILP32 model and 64 bits in the
LP64 model, there might be cases where what was previously defined as a long
is neither appropriate nor necessary. In this case, it might be possible to
use a more portable derived type.
Related to this, a number of derived types might have changed under the LP64
data model for the reason stated above. For example, pid_t
remains a long
in the 32-bit environment, but under the 64-bit environment, a pid_t
is an int
. For a list of derived types modified for the
LP64 compilation environment, see Appendix A, Changes in Derived Types.