Go to main content

Oracle® Solaris 64-bit Developer's Guide

Exit Print View

Updated: March 2019
 
 

4.5 Other Considerations When Converting to 64-bit

The remaining guidelines highlight common problems encountered when converting an application to a full 64-bit program.

4.5.1 Check for Derived Types That Have Grown in Size

A number of derived types now represent 64-bit quantities in the 64-bit application compilation environment. This change does not affect 32-bit applications; however, any 64-bit applications that consume or export data described by these types must be re-evaluated. For example, in applications that directly manipulate the utmp or utmpx files, do not attempt to directly access these files. Instead, for correct operation in the 64-bit application environment, use the getutxent() and related family of functions. For more information, see getutxent(3C), utmpx(4), and utmp(4) man pages.

A list of changed derived types is included in Changes in Derived Types.

4.5.2 Check for Side Effects of Changes

Be aware that a type change in one area can result in an unexpected 64-bit conversion in another area. For example, check all the callers of a function that previously returned an int and now returns an ssize_t.

4.5.3 Check Whether Literal Uses of long Still Make Sense

A variable that is defined as a long is 32-bit in the ILP32 data-type model and 64-bit in the LP64 data-type model. Where possible, avoid problems by redefining the variable and use a more portable derived type.

Related to this issue, a number of derived types have changed under the LP64 data-type model. 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 Changes in Derived Types.

4.5.4 Check Use #ifdef for Explicit 32-Bit Versus 64-Bit Prototypes

In some cases, specific 32-bit and 64-bit versions of an interface are unavoidable. You can distinguish these versions by specifying the _LP64 or _ILP32 feature test macros in the headers. Similarly, code that runs in 32-bit and 64-bit environments needs to use the appropriate #ifdefs, depending on the compilation mode.

4.5.5 Calling Convention Changes

When you pass structures by value and compile the code for a 64-bit environment, the structure is passed in registers rather than as a pointer to a copy if it is small enough. This process can cause problems if you try to pass structures between C code and handwritten assembly code.

Floating-point parameters work in a similar fashion: some floating-point values passed by value are passed in floating-point registers.

4.5.6 Algorithmic Changes

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.