JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Solaris 64-bit Developer's Guide
search filter icon
search icon

Document Information


1.  64-bit Computing

2.  When to Use 64-bit

3.  Comparing 32-bit Interfaces and 64-bit Interfaces

4.  Converting Applications

Data Model

Implementing Single-Source Code

Feature Test Macros

Derived Types

<sys/types.h> File

<inttypes.h> File

Fixed-Width Integer Types

uintptr_t and Other Helpful Types

Constant Macros

Limits Defined by <inttypes.h>

Format String Macros

Tools Support

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

Sign Extension

Use Pointer Arithmetic Instead of Address Arithmetic

Repacking a Structure

Check Unions

Specify Constant Types

Beware of Implicit Declaration

sizeof is an unsigned long

Use Casts to Show Your Intentions

Check Format String Conversion Operation

Other Considerations

Derived Types That Have Grown in Size

Check for Side Effects of Changes

Check Whether Literal Uses of long Still Make Sense

Use #ifdef for Explicit 32-bit Versus 64-bit Prototypes

Algorithmic Changes

Checklist for Getting Started

Sample Program

5.  The Development Environment

6.  Advanced Topics

A.  Changes in Derived Types

B.  Frequently Asked Questions (FAQs)


Other Considerations

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

Derived Types That Have Grown in Size

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.

Check for Side Effects of Changes

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.

Check Whether Literal Uses of long Still Make Sense

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.

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. 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.

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.