Go to main content
Oracle® Developer Studio 12.6: C User's Guide

Exit Print View

Updated: July 2017

8.2 Implementing Single Source Code

The following sections describe some of the available resources that you can use to write single-source code that supports 32-bit and 64-bit compilation.

8.2.1 Derived Types

Using the system derived types to make code safe for both the 32-bit and the 64-bit compilation environment is good programming practice. When you use derived data-types, only the system derived types need to change for data model changes, or porting.

The system include files <sys/types.h> and <inttypes.h> contain constants, macros, and derived types that are helpful in making applications 32-bit and 64-bit safe. <sys/types.h>

Include <sys/types.h> in an application source file to gain access to the definition of _LP64 and _ILP32. This header also contains a number of basic derived types that should be used whenever appropriate. In particular, the following are of special interest:

  • clock_t represents the system times in clock ticks.

  • dev_t is used for device numbers.

  • off_t is used for file sizes and offsets.

  • ptrdiff_t is the signed integral type for the result of subtracting two pointers.

  • size_t reflects the size, in bytes, of objects in memory.

  • ssize_t is used by functions that return a count of bytes or an error indication.

  • time_t counts time in seconds.

All of these types remain 32-bit quantities in the ILP32 compilation environment and grow to 64-bit quantities in the LP64 compilation environment. <inttypes.h>

The include file <inttypes.h> provides constants, macros, and derived types that help you make your code compatible with explicitly sized data items, independent of the compilation environment. It contains mechanisms for manipulating 8-bit, 16-bit, 32-bit, and 64-bit objects. The following is a discussion of the basic features provided by <inttypes.h>:

  • Fixed-width integer types.

  • Helpful types such as uintptr_t

  • Constant macros

  • Limits

  • Format string macros

The following sections provide more information about the basic features of <inttypes.h>.

Fixed-Width Integer Types

The fixed-width integer types that <inttypes.h> provides include signed integer types such as int8_t, int16_t, int32_t, and int64_t, and unsigned integer types such as uint8_t, uint16_t, uint32_t, and uint64_t.

Derived types, defined as the smallest integer types that can hold the specified number of bits, include int_least8_t,…, int_least64_t, uint_least8_t,…, uint_least64_t.

Using an int or unsigned int for such operations as loop counters and file descriptors is safe. Using a long for an array index is also safe. However, do not use these fixed-width types indiscriminately. Use fixed-width types for explicit binary representations of the following items:

  • On-disk data

  • Over the data wire

  • Hardware registers

  • Binary interface specifications

  • Binary data structures

Helpful Types Such as unintptr_t

The <inttypes.h> file includes signed and unsigned integer types large enough to hold a pointer. These are given as intptr_t and uintptr_t. In addition, <inttypes.h> provides intmax_t and uintmax_t, which are the longest (in bits) signed and unsigned integer types available.

Use the uintptr_t type as the integral type for pointers instead of a fundamental type such as unsigned long. Even though an unsigned long is the same size as a pointer in both the ILP32 and LP64 data models, using uintptr_t means that only the definition of uintptr_t is affected if the data model changes. This method makes your code portable to many other systems and is also a clearer way to express your intentions in C.

The intptr_t and uintptr_t types are extremely useful for casting pointers when you want to perform address arithmetic. Use intptr_t and uintptr_t types instead of long or unsigned long for this purpose.

Constant Macros

Use the macros INT8_C(c), …, INT64_C(c), UINT8_C(c),…, UINT64_C(c) to specify the size and sign of a given constant. Basically, these macros place an l, ul, ll, or ull at the end of the constant, if necessary. For example, INT64_C(1) appends ll to the constant 1 for ILP32 and an l for LP64.

Use the INTMAX_C(c) and UINTMAX_C(c) macros to make a constant the biggest type. These macros can be very useful for specifying the type of constants described in Converting to the LP64 Data Type Model.


The limits defined by <inttypes.h> are constants that specify the minimum and maximum values of various integer types. These limits include minimum and maximum values for each of the fixed-width types such as INT8_MIN,…, INT64_MIN, INT8_MAX,…, INT64_MAX, and their unsigned counterparts.

The <inttypes.h> file also provides the minimum and maximum values for each of the least-sized types. These types include INT_LEAST8_MIN,…, INT_LEAST64_MIN, INT_LEAST8_MAX,…, INT_LEAST64_MAX, as well as their unsigned counterparts.

Finally, <inttypes.h> defines the minimum and maximum values of the largest supported integer types. These types include INTMAX_MIN and INTMAX_MAX and their corresponding unsigned versions.

Format String Macros

The <inttypes.h> file includes the macros that specify the printf(3C) and scanf(3C) format specifiers. Essentially, these macros prepend the format specifier with an l or ll to identify the argument as a long or long long, given that the number of bits in the argument is built into the name of the macro.

Some macros for printf(3C) print both the smallest and largest integer types in decimal, octal, unsigned, and hexadecimal formats, as shown in the following example.

int64_t i;
printf("i =%" PRIx64 "\n", i);

Similarly, macros for scanf(3C) read both the smallest and largest integer types in decimal, octal, unsigned, and hexadecimal formats.

uint64_t u;
scanf("%" SCNu64 "\n", &u);

Do not use these macros indiscriminately. They are best used in conjunction with the fixed-width types discussed in Fixed-Width Integer Types.

8.2.2 Checking With lint

The lint program’s -errchk option detects potential 64-bit porting problems. You can also specify cc -v, which directs the compiler to perform additional and more strict semantic checks. The -v option also enables certain lint-like checks on the named files.

When you enhance code to be 64-bit safe, use the header files present in the Oracle Solaris operating system because these files have the correct definition of the derived types and data structures for the 64-bit compilation environment.

Use lint to check code that is written for both the 32-bit and the 64-bit compilation environment. Specify the -errchk=longptr64 option to generate LP64 warnings. Also use the -errchk=longptr64 flag, which checks portability to an environment for which the size of long integers and pointers is 64 bits and the size of plain integers is 32 bits. The -errchk=longptr64 flag checks assignments of pointer expressions and long integer expressions to plain integers, even when explicit casts are used.

Use the -errchk=longptr64,signext option to find code where the normal ISO C value-preserving rules allow the extension of the sign of a signed-integral value in an expression of unsigned-integral type.

Use the -m64 option of lint when you want to check code that you intend to run in the Oracle Solaris 64-bit compilation environment only.

lint warnings show the line number of the offending code, a message that describes the problem, and an indication of whether a pointer is involved. The warning message also indicates the sizes of the involved data types. When you know a pointer is involved and you know the size of the data types, you can find specific 64-bit problems and avoid the preexisting problems between 32-bit and smaller types.

Be aware, however, that even though lint gives warnings about potential 64-bit problems, it cannot detect all problems. Also, in many cases, code that is intentional and correct for the application generates a warning.

You can suppress the warning for a given line of code by placing a comment of the form “NOTE(LINTED(“<optional message”>))” on the previous line. This comment directive is useful when you want lint to ignore certain lines of code such as casts and assignments. Exercise extreme care when you use the “NOTE(LINTED(“<optional message”>))” comment because it can mask real problems. When you use NOTE, include note.h. Refer to the lint man page for more information.