Contained WithinFind More DocumentationFeatured Support Resources |  Download this book in PDF (584 KB)
Chapter 4 Converting ApplicationsTwo basic issues that regard conversion arise for applications developers:
Trying to maintain a single source with as few #ifdefs as possible is usually better than trying to maintain multiple source trees. This chapter provides guidelines for writing code that works correctly in both 32-bit environments and 64-bit environments. At best, the conversion of current code might require only a recompilation and relinking with the 64-bit libraries. However, for those cases where code changes are required, this chapter discusses the tools that help make conversion easier. Data ModelAs stated previously, the biggest difference between the 32-bit environment and 64-bit environment is the change in two fundamental data types. The C data-type model used for 32-bit applications is the ILP32 model, so named
because The following sample program, foo.c, directly illustrates the effect of the LP64 data model in contrast to the ILP32 data models. The same program can be compiled as either a 32–bit program or a 64–bit program. #include <stdio.h>
int
main(int argc, char *argv[])
{
(void) printf("char is \t\t%lu bytes\n", sizeof (char));
(void) printf("short is \t%lu bytes\n", sizeof (short));
(void) printf("int is \t\t%lu bytes\n", sizeof (int));
(void) printf("long is \t\t%lu bytes\n", sizeof (long));
(void) printf("long long is \t\t%lu bytes\n", sizeof (long long));
(void) printf("pointer is \t%lu bytes\n", sizeof (void *));
return (0);
}
The result of 32–bit compilation is:
The result of 64–bit compilation is:
Note – The default compilation environment is designed to maximize portability, that is, to create 32–bit applications. The standard relationship between C integral types still holds true. sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long) Table 4–1 lists the basic C types, and their corresponding sizes in bits in the data type models for both LP32 and LP64. Table 4–1 Data Type Sizes in Bits
Some older 32-bit applications use In addition, declarations and casts become very important in showing what is intended. How expressions are evaluated can be affected when the types change. The effects of standard C conversion rules are influenced by the change in data-type sizes. To adequately show what is intended, you might need to declare the types of constants. Casts might also be needed in expressions to make certain that the expression is evaluated the way that you intended. Correct evaluation of expressions is particularly crucial in the case of sign extension, where explicit casting might be essential to achieve the intended effect. Other problems arise with built-in C operators, format strings, assembly language, and compatibility and interoperability. The rest of this chapter advises you how to overcome these problems by:
Implementing Single-Source CodeThe sections that follow describe some of the resources available to application developers that help you write single-source code that supports both 32–bit and 64–bit compilation. 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. While a detailed discussion of these is beyond the scope of this document, some are discussed in the sections that follow, as well as in Appendix A, Changes in Derived Types. Feature Test MacrosAn application source file that includes <sys/types.h> makes the definitions of the programming model symbols, _LP64 and _ILP32, available through inclusion of <sys/isa_defs.h>. For information about preprocessor symbols (_LP64 and _ILP32) and macros (_LITTLE_ENDIAN and _BIG_ENDIAN6), see types(3HEAD). Derived TypesUsing the system derived types helps make code 32-bit and 64-bit safe, since the derived types themselves are safe for both the ILP32 and LP64 data models. In general, using derived types to allow for change is good programming practice. Should the data model change in the future, or when porting to a different platform, only the system derived types need to change rather than the application. <sys/types.h> FileThe <sys/types.h> header contains a number of basic derived types that should be used whenever appropriate. In particular, the following are of special interest:
All of these types remain 32-bit quantities in the ILP32 compilation environment and grow to 64-bit quantities in the LP64 compilation environment. The use of some of these types is explained in more detail later in this chapter under Guidelines for Converting to LP64.
|
% cc -o test64 -xarch=v9 test.c % ./test64 addr 0xffffffff80000000 addr 0x80000000 % |
When this same example is compiled as a 32-bit program it does not display any sign extension:
% cc -o test32 test.c % ./test32 addr 0x80000000 addr 0x80000000 % |
Use Pointer Arithmetic Instead of Address Arithmetic
In general, using pointer arithmetic works better than address arithmetic because pointer arithmetic is independent of the data model, whereas address arithmetic might not be. It usually leads to simpler code as well. For example,
int *end; int *p; p = malloc(4 * NUM_ELEMENTS); end = (int *)((unsigned int)p + 4 * NUM_ELEMENTS);
produces the warning:
warning: conversion of pointer loses bits
The following code will produce clean results:
int *end; int *p; p = malloc(sizeof (*p) * NUM_ELEMENTS); end = p + NUM_ELEMENTS;
Repacking a Structure
Extra padding may be added to a structure by the compiler to meet alignment requirements as long and pointer fields grow to 64 bits for LP64. For both the SPARCV9 ABI and the amd64 ABI, all types of structures are aligned to at least the size of the largest quantity within them. A simple rule for repacking a structure is to move the long and pointer fields to the beginning of the structure and rearrange the rest of the fields—usually, but not always, in descending order of size, depending on how well they can be packed. For example,
struct bar {
int i;
long j;
int k;
char *p;
}; /* sizeof (struct bar) = 32 */
For better results, use:
struct bar {
char *p;
long j;
int i;
int k;
}; /* sizeof (struct bar) = 24 */
Note –
The alignment of fundamental types changes between the i386 and amd64 ABIs. See Alignment Issues.
Check Unions
Be sure to check unions because their fields might have changed sizes between ILP32 and LP64. For example,
typedef union {
double _d;
long _l[2];
} llx_t;
should be:
typedef union {
double _d;
int _l[2];
} llx_t;
Specify Constant Types
A loss of data can occur in some constant expressions because of lack of precision. These types of problems are very hard to find. Be explicit about specifying the type(s) in your constant expressions. Add some combination of {u,U,l,L} to the end of each integer constant to specify its type. You might also use casts to specify the type of a constant expression. For example,
int i = 32; long j = 1 << i; /* j will get 0 because RHS is integer expression */
should be:
int i = 32; long j = 1L << i;
Beware of Implicit Declaration
For some compilation modes, the compiler might assume the type int for
any function or variable that is used in a module and not defined or declared externally.
Any longs and pointers used in this way are truncated by the compiler's
implicit int declaration. The appropriate extern declaration
for a function or variable should be placed in a header and not in the C module. The
header should then be included by any C module that uses the function or variable.
In the case of a function or variable defined by the system headers, the proper header
should still be included in the code.
For example, because getlogin() is not declared, the following code:
int
main(int argc, char *argv[])
{
char *name = getlogin()
printf("login = %s\n", name);
return (0);
}
produces the warnings:
warning: improper pointer/integer combination: op "=" warning: cast to pointer from 32-bit integer implicitly declared to return int getlogin printf
For better results, use::
#include <unistd.h>
#include <stdio.h>
int
main(int argc, char *argv[])
{
char *name = getlogin();
(void) printf("login = %s\n", name);
return (0);
}
sizeof is an unsigned long
In the LP64 environment, sizeof has the effective type of size_t which is implemented as an unsigned long. Occasionally, sizeof is passed to a function expecting an argument of type int,
or is assigned or cast to an int. In some cases, this truncation might
cause loss of data. For example,
long a[50]; unsigned char size = sizeof (a);
produces the warnings:
warning: 64-bit constant truncated to 8 bits by assignment warning: initializer does not fit or is out of range: 0x190
Use Casts to Show Your Intentions
Relational expressions can be tricky because of conversion rules. You should be very explicit about how you want the expression to be evaluated by adding casts wherever necessary.
Check Format String Conversion Operation
The format strings for printf(3C), sprintf(3C), scanf(3C),
and sscanf(3C) might need
to be changed for long or pointer arguments. For pointer arguments, the
conversion operation given in the format string should be %p to
work in both the 32-bit and 64-bit environments. For example,
char *buf; struct dev_info *devi; ... (void) sprintf(buf, "di%x", (void *)devi);
produces the warning:
warning: function argument (number) type inconsistent with format sprintf (arg 3) void *: (format) int
Use the following code to produce clean results:
char *buf; struct dev_info *devi; ... (void) sprintf(buf, "di%p", (void *)devi);
Also check to be sure that the storage pointed to by buf is large
enough to contain 16 digits. For long arguments, the long size
specification, l, should be prepended to the conversion operation
character in the format string. For example,
size_t nbytes;
ulong_t align, addr, raddr, alloc;
printf("kalloca:%d%%%d from heap got %x.%x returns %x\n",
nbytes, align, (int)raddr, (int)(raddr + alloc), (int)addr);
produces the warnings:
warning: cast of 64-bit integer to 32-bit integer warning: cast of 64-bit integer to 32-bit integer warning: cast of 64-bit integer to 32-bit integer
The following code will produce clean results:
size_t nbytes;
ulong_t align, addr, raddr, alloc;
printf("kalloca:%lu%%%lu from heap got %lx.%lx returns %lx\n",
nbytes, align, raddr, raddr + alloc, addr);
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.
Checklist for Getting Started
Assuming you need to convert your code to 64-bit, the following checklist might be helpful:
-
Read this entire document with an emphasis on the Guidelines for Converting to LP64.
-
Review all data structures and interfaces to verify that these are still valid in the 64-bit environment.
-
Include <sys/types.h> in your code to pull in the _ILP32 or _LP64 definitions as well as many basic derived types.
-
Move function prototypes and external declarations with non-local scope to headers and include these headers in your code.
-
Run lint(1) using the -errchk=longptr64 and review each warning individually, being aware that not all warnings require a change to the code. Depending on the resulting changes, you might also want to run lint(1) again, both in 32–bit and 64–bit modes.
-
Compile code as both 32-bit and 64-bit, unless the application is being provided only as 64-bit.
-
Test the application by executing the 32-bit version on the 32-bit operating system, and the 64-bit version on the 64-bit operating system. You could include testing the 32-bit version on the 64-bit operating system, but this is not necessary.
Sample Program
The following sample program, foo.c, directly illustrates the effect of the LP64 data model in contrast to the ILP32 data models. The same program can be compiled as either a 32–bit program or a 64–bit program.
#include <stdio.h>
int
main(int argc, char *argv[])
{
(void) printf("char is \t\t%lu bytes\n", sizeof (char));
(void) printf("short is \t%lu bytes\n", sizeof (short));
(void) printf("int is \t\t%lu bytes\n", sizeof (int));
(void) printf("long is \t\t%lu bytes\n", sizeof (long));
(void) printf("long long is \t\t%lu bytes\n", sizeof (long long));
(void) printf("pointer is \t%lu bytes\n", sizeof (void *));
return (0);
}
The result of 32–bit compilation is:
% cc -O -o foo32 foo.c % foo32 char is 1 bytes short is 2 bytes int is 4 bytes long is 4 bytes long long is 8 bytes pointer is 4 bytes |
The result of 64–bit compilation is:
% cc -xarch=generic64 -O -o foo64 foo.c % foo64 char is 1 bytes short is 2 bytes int is 4 bytes long is 8 bytes long long is 8 bytes pointer is 8 bytes |
Note –
The default compilation environment is designed to maximize portability, that is, to create 32–bit applications.