Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Studio 12.3: C User's Guide Oracle Solaris Studio 12.3 Information Library |
1. Introduction to the C Compiler
2. C-Compiler Implementation-Specific Information
7. Converting Applications for a 64-Bit Environment
7.1 Overview of the Data Model Differences
7.2 Implementing Single Source Code
Helpful Types Such as unintptr_t
7.3 Converting to the LP64 Data Type Model
7.3.1 Integer and Pointer Size Change
7.3.2 Integer and Long Size Change
7.3.4 Pointer Arithmetic Instead of Integers
7.3.8 Beware of Implicit Declarations
7.3.9 sizeof( ) Is an Unsigned long
7.3.10 Use Casts to Show Your Intentions
7.3.11 Check Format String Conversion Operation
7.4 Other Conversion Considerations
7.4.1 Note: Derived Types That Have Grown in Size
7.4.2 Check for Side Effects of Changes
7.4.3 Check Literal Uses of long Still Make Sense
7.4.4 Use #ifdef for Explicit 32-bit Versus 64-bit Prototypes
7.5 Checklist for Getting Started
8. cscope: Interactively Examining a C Program
A. Compiler Options Grouped by Functionality
B. C Compiler Options Reference
C. Implementation-Defined ISO/IEC C99 Behavior
E. Implementation-Defined ISO/IEC C90 Behavior
H. Oracle Solaris Studio C: Differences Between K&R C and ISO C
The remaining guidelines highlight common problems encountered when converting an application to a full 64-bit program.
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 need to be re-evaluated. For example, o in applications that directly manipulate the utmp(4) or utmpx(4) files, do not attempt to directly access these files. For correct operation in the 64-bit application environment,use the getutxent(3C) and related family of functions instead.
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.
A variable that is defined as a long is 32 bits in the ILP32 data-type model and 64 bits 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.
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.
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.
After your code is safe for the 64-bit environment, review your code 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 modify your code appropriately.