| Skip Navigation Links | |
| Exit Print View | |
|
Solaris 64-bit Developer's Guide |
3. Comparing 32-bit Interfaces and 64-bit Interfaces
Implementing Single-Source Code
uintptr_t and Other Helpful Types
Limits Defined by <inttypes.h>
lint for 32-bit and 64-bit Environments
Guidelines for Converting to LP64
Do Not Assume int and Pointers Are the Same Size
Do Not Assume int and long Are the Same Size
Use Pointer Arithmetic Instead of Address Arithmetic
Beware of Implicit Declaration
Use Casts to Show Your Intentions
Check Format String Conversion Operation
Derived Types That Have Grown in Size
Check for Side Effects of Changes
Check Whether Literal Uses of long Still Make Sense
5. The Development Environment
The remaining guidelines highlight common problems encountered when converting an application to a full 64–bit program.
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.
In some cases, specific 32-bit and 64-bit versions of an interface are unavoidable. In the headers, these would be distinguishable by the use of the _LP64 or _ILP32 feature test macros. Similarly, code that is to work in 32-bit and 64-bit environments might also need to utilize the appropriate #ifdefs, depending on the compilation mode.
After code has been made 64-bit safe, review it again to verify that the algorithms and data structures still make sense. The data types are larger, so data structures might use more space. The performance of your code might change as well. Given these concerns, you might need to adapt your code appropriately.
|