The UNIX System -- 64bit and Data Size Neutrality (original) (raw)

What is UNIX®?

UNIX 98 |UNIX 03 |UNIX V7

The Single UNIX Specification Version 4

The Single UNIX Specification Version 3

ISO/IEC 9945

UNIX System API Tables

UNIX Certification

Resources

Test Tool Downloads

Questions and Answers

Contacts

The Platform Forum

• The Single UNIX Specification
• The UNIX Certification Program

Data Size Neutrality and 64-bit Support

The Single UNIX Specification, Version 2 provides enhanced support for 64-bit programming models by being n-bit clean and data size neutral. This article is a brief introduction to 64-bit programming models, data size neutrality, and application porting issues.

Introduction

When the UNIX operating system was first created in 1969 it was developed to run on a 16-bit computer architecture. The C language of the time supported 16-bit integer and pointer data types and also supported a 32-bit integer data type that could be emulated on hardware which did not support 32-bit arithmetic operations.

When 32-bit computer architectures, which supported 32-bit integer arithmetic operators and 32-bit pointers, were introduced in the late 1970s, the UNIX operating system was quickly ported to this new class of hardware platforms. The C language data model developed to support these 32-bit architectures quickly evolved to consist of a 16-bit short-integer type, a 32-bit integer type, and a 32-bit pointer. During the 1980s, this was the predominant C data model available for 32-bit UNIX platforms.

To describe these two data models in modern terms, the 16-bit UNIX platforms used an IP16 data model, while 32-bit UNIX platforms use the ILP32 programming model. The notation describes the width assigned to the basic data types; for example, ILP32 denotes thatint(I),long(L), andpointer(P) types are all 32-bit entities. This notation is used extensively throughout this article.

The first UNIX standardization effort was begun in 1983 by a /usr/group committee. This work was merged into the work program of the IEEE POSIX committee in 1985. By 1988, both POSIX and X/Open committees had developed detailed standards and specifications that were based upon the predominant UNIX implementations of the time. These committees endeavored to develop architecture-neutral definitions that could be implemented on any hardware architecture.

The transition from 16-bit to 32-bit processor architectures happened quite rapidly just before the UNIX standardization work was begun. Since the specifications were based on existing practice and the predominant data model did not change during this gestation period, some dependencies upon the ILP32 data model were inadvertently incorporated into the final specifications.

Most of today's 32-bit UNIX platforms use the ILP32 data model. However another data model, the LP32 model, is also very popular for other operating systems. The majority of C-language programs written for Microsoft Windows 3.1 are written for the Win-16 API which uses the LP32 data model. The Apple Macintosh also uses the LP32 data model.

32-bit platforms have a number of limitations which are increasingly a source of frustration to developers of large applications, such as databases, who wish to take advantage of advances in computer hardware. There is much discussion today in the computer industry about the barrier presented by 32-bit addresses. 32-bit pointers can only address 4GB of virtual address space. There are ways of overcoming this limitation, but application development is more complicated and performance is significantly reduced. Until recently the size of a data file could not exceed 4GB. However, the 4GB file size limitation was overcome by the Large File Summit extensions which are included in XSH, Issue 5.

Disk storage has been improving in real density at the rate of 70% compounded annually, and drives of 8GB and larger are readily available. Memory prices have not dropped as sharply, but 64MB chips are readily available. CPU processing power continues to increase by about 50% every 18 months, providing the power to process ever larger quantities of data. This conjunction of technological forces, along with the continued demand for systems capable of supporting ever larger databases and simulation models and full-motion video, have generated requirements for support of larger addressing structures.

A number of 64-bit processors are now available, and the transition from 32-bit to 64-bit architectures is rapidly occurring amongst all the major hardware vendors. 64-bit UNIX platforms do not suffer from the file size or flat address space limitations of 32-bit platforms. Applications can access files that occupy terabytes of disk space because 64-bit file offsets are possible. Similarly, applications can now theoretically access terabytes of memory because pointers can be 64 bits. More physical memory results in faster operations. The performance of memory-mapped file access, caching, and swapping, is greatly improved. 64-bit virtual addresses simplify the design of large applications. All the major database vendors now support 64-bit platforms because of dramatically improved performance for very large database applications available on very large memory (VLM) systems.

The world is currently dominated by 32-bit computers, a situation that is likely to continue to exist for the near future. These computers run 16 or 32-bit applications or some mixture of the two. Meanwhile, 64-bit computers will run 32-bit code, 64-bit code, or mixtures of the two (and perhaps even some 16-bit code). New 64-bit applications and operating systems must integrate smoothly into this environment. Key issues facing the computing industry are the interchange of data between 64 and 32-bit systems (in some cases on the same system) and the cost of maintaining software in both environments. Such interchange is especially needed for large application suites such as database systems, where one may want to distribute most of the applications as 32-bit binaries that run across a large installed base, but be able to choose 64-bits for a few crucial applications.

64-bit Data Models

Prior to the introduction of 64-bit platforms, it was generally believed that the introduction of 64-bit UNIX operating systems would naturally use the ILP64 data model. However, this view was too simplistic and overlooked optimizations that could be obtained by choosing a different data model.

Unfortunately, the C programming language does not provide a mechanism for adding new fundamental data types. Thus, providing 64-bit addressing and integer arithmetic capabilities involves changing the bindings or mappings of the existing data types or adding new data types to the language.

ISO/IEC 9899:1990, Programming Languages - C (ISO C) left the definition of theshort int, theint, thelong int, and thepointerdeliberately vague to avoid artificially constraining hardware architectures that might benefit from defining these data types independent from the other. The only constraints were thatints must be no smaller thanshorts, andlongs must be no smaller thanints, andsize_tmust represent the largest unsigned type supported by an implementation. It is possible, for instance, to define ashortas 16 bits, anintas 32 bits, alongas 64 bits and apointeras 128 bits. The relationship between the fundamental data types can be expressed as:

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) = sizeof(size_t)

Ignoring non-standard types, all three of the following 64-bit pointer data models satisfy the above relationship:

• LP64 (also known as 4/8/8)
• ILP64 (also known as 8/8/8)
• LLP64 (also known as 4/4/8).

The differences between the three models lies in the non-pointer data types. The table below details the data types for the above three data models and includes LP32 and ILP32 for comparison purposes.

When the width of one or more of the C data types is changed, applications may be affected in various ways. These effects fall into two main categories:

• Data objects, such as a structure, defined with one of the 64-bit data types will be different in size from those declared in an identical way on a 16 or 32-bit system.
• Common assumptions about the relationships between the fundamental data types may no longer be valid in a 64-bit data model. Applications which depend on those relationships often cease to work properly when compiled on a 64-bit platform. A typical assumption made by many application developers is that:
  sizeof(int) = sizeof(long) = sizeof(pointer)
  This relationship is not codified in any C programming standard, but it is valid for the ILP32 data model. However, it is not valid for two of the three 64-bit data models described above, nor is it valid for the LP32 data model.

The ILP64 data model attempts to maintain the relationship betweenint,long, andpointerwhich exists in the ILP32 model by making all three types the same size. Assignment of a pointer to anintor alongwill not result in data loss.

The downside of this model is that it depends on the addition of a new 32-bit data type such asint32to handle true 32-bit quantities. There is thus a potential for conflict with existingtypedefs in applications. An application which was developed on an ILP32 platform, and subsequently ported to an ILP64 platform, may be forced to make frequent use of theint32data type to preserve the size and alignment of data because of interoperability requirements or binary compatibility with existing data files.

The LLP64 data model preserves the relationship betweenintandlongby leaving both as 32-bit types. Data objects, such as structures, which do not contain pointers will be the same size as on a 32-bit system. This model is sometimes described as a 32-bit model with 64-bit addresses. Most of the run-time problems associated with the assumptions between the sizes of the data types are related to the assumption that a pointer will fit in anint. To solve this class of problems,intorlongvariables which should be 64-bits in length are changed tolong long(orint64), a non-standard data type. This data model is thus again dependent on the introduction of a new data type. Again there is potential for conflict with existingtypedefs in applications.

The LP64 data model takes the middle road. 8, 16, and 32-bit scalar types (char,short, andint) are provided to support objects that must maintain size and alignment with 32-bit systems. A 64-bit type,long, is provided to support the full arithmetic capabilities, and is available to use in conjunction with pointer arithmetic. Applications that assign addresses to scalar objects need to specify the object aslonginstead ofint.

In the LP64 data model, data types are natural. Each scalar type is larger than the preceding type. No new data types are required. As a language design issue, the purpose of havinglongin the language anticipates cases where there is an integral type longer thanint. The fact thatintandlongrepresent different width data types is a natural and common sense approach, and is the standard in the PC world whereintis 16-bits andlongis 32-bits.

A major test for any C data model is its ability to support the very large existing UNIX applications code base. The investment in code, experience, and data surrounding these applications is the largest determiner of the rate at which new technology is adopted and spread. In addition, it must be easy for an application developer to build code which can be used in both existing and new environments.

The UNIX development community is driven technically by a set of API agreements embodied in standards and specifications documents from groups such as X/Open, IEEE, ANSI, and ISO. These documents were developed over many years to codify existing practice and define agreement on new capabilities. As a result these specifications are of major value to the system developers, application developers, and end-users. There are numerous test suites which verify that implementations correctly embody the details of a specification and certify that fact to interested parties. Any 64-bit data model cannot invalidate large portions of these specifications and expect to achieve wide adoption.

A number of vendors have extensive experience with the LP64 data model. By far, the largest body of existing 32-bit code already modified for 64-bit environments runs on LP64 platforms. Experience has shown that it is relatively easy to modify existing code so that it can be compiled on either an 32-bit or 64-bit platform. Interoperability with existing ILP32 platforms is well proven and is not an issue. At least one LP64-based operating system (Digital UNIX V4.0) has met and passed the majority of existing verification suites and has obtained the UNIX 95 brand.

A small number of ILP64-based platforms have also shipped. These have demonstrated that it is feasible to complete the implementation of an ILP64 environment. However, as of early 1997, no LLP64 or ILP64-based systems have achieved the same level of standards conformance or met the requirements of the UNIX 95 brand.

Although the number of applications written in C requiring a large virtual address space is growing rapidly, there has not been a requirement to date for a 64-bitintdata type. The majority of existing 64-bit applications previously ran only on 32-bit platforms, and had no expectation of a greater range for theintdata type. The extra 32 bits of data space in a 64-bitintwould appear to be wasted. Any future applications which require a larger scalar data type can use thelongtype.

Nearly all applications moving from a 32-bit platform require some minor modifications to handle 64-bit pointers, especially where erroneous assumptions about the relative size ofintandpointerdata types were made. Common assumptions about the relative sizes ofint,char,short, andfloatdata types generally do not cause problems on LP64 platforms (since the sizes of those data types are identical to those on an ILP32 platform), but do so on an ILP64 platform.

Other language implementations will continue to support a 32-bitinttype. For example, the FORTRAN-77 standard requires that the type INTEGER be the same size as REAL, which is half the size of DOUBLE PRECISION. This, together with customer expectations, means that FORTRAN-77 implementations will generally leave INTEGER as a 32-bit type, even on 64-bit platforms. A significant number of applications use C and FORTRAN together, either calling each other or sharing data files. Such applications have been amongst the first to move to 64-bit environments. Experience has shown that it is usually easier to modify the data sizes and types on the C side than the FORTRAN side of such applications. These applications will continue to require a 32-bitintdata type in C regardless of the size of theintdata type.

In 1995, a number of major UNIX vendors agreed to standardize on the LP64 data model for a number of reasons:

• Experience suggests that neither the LP64 nor the ILP64 data models provide a painless porting path from a 32-bit platform, but that all other things being equal, the smaller data types in the LP64 data model enable better application performance.
• A crucial investment for end-users is the existing data built up over decades in their computer systems. Any proposed solution must make it easy to utilize such data on a continuing basis. Unfortunately, the ILP64 data model does not provide a natural way to describe 32-bit data types, and must resort to non-portable constructs such asint32to describe such types. This is likely to cause practical problems in producing code which can run on both 32 and 64-bit platforms without numerous**#ifdef**constructions. It has been possible to port large quantities of code to LP64 platforms without the need to make such changes, while maintaining the investment made in data sets, even in cases where the typing information was not made externally visible by the application.
• Mostints in existing applications can remain as 32 bits in a 64-bit environment; only a small number are expected to be the same size aspointerorlong. Under the ILP64 data model, mostints will need to change toint32. However,int32does not behave like a 32-bitint. Instead,int32is likeshortin that all operations have to be converted toint(64-bits, sign extended) and performed in 64-bit arithmetic. Thus,int32in the ILP64 data model is not exactly the same asintin the ILP32 data model. These differences may cause subtle and hard-to-find bugs.
• Instruction cycle penalties are incurred whenever additional cycles are required to properly implement the semantics of the intended data model. For example, in the LP64 data model it is only necessary to perform sign extension onintwhen you have a mixed expression includinglongs. However, most integral expressions do not includelongs and compilers can be made smart enough to only sign extend when necessary.
• intis by far the most frequent data type to be found (statically and sometimes dynamically) within C and C++ programs. 64-bit integers require twice as much space as 32-bit integers. Applications using 64-bit integers consume additional memory and CPU cycles transporting that memory throughout the system. Furthermore, the latency penalty of 64-bit integers can be enormous, especially to disk, where it can exceed 1,000,000 CPU cycles (3 nsec to 3 msec). The memory size penalty for unneeded 64-bit integers could therefore be very high for some applications.
• Portability, especially for combined FORTRAN and C applications, is enhanced by the LP64 data model, and the most common types of problems that can occur are susceptible to automatic detection.
• Interoperability is improved by the ability to use a standard data type to declare data structures that can be used in both 32-bit and 64-bit environments.
• Standards conformance has been demonstrated both in the practical sense by the porting of many programs and in the formal sense of compliance with industry standards through verification test suites.
• Transition from the current industry practice is smooth and direct following a path grooved with experience and demonstrated success.
• No new non-portable data types are required. The data model makes natural use of the C fundamental data types.

Data Size Neutrality

When it was understood that the Single UNIX Specification was constraining system implementations that were other than ILP32, the relevant specifications were reviewed and recommendations drafted to make these specifications data size- and architecture-neutral. These recommendations were incorporated into the Single UNIX Specification, Version 2 published in 1997.

The following is a summary of the changes that were made. Changes are identified with respect to the CAE Specifications which made up the previous version of the Single UNIX Specification.

System Interface Definitions, Issue 5 (XBD)

The following text was added to System Interface Definitions, Issue 4, Version 2 (XBD), Chapter 10, page 130, point 6, as a fourth bullet item:

"Ranges greater than those listed here are allowed."

This section describes the argument syntax of the standard utilities and introduces terminology used throughout the Single UNIX Specification for describing the arguments processed by the utilities. It was updated so that the maximum value of a numerical argument is allowed to be greater than a 32-bit value, thus permitting support of 64-bit values.

System Interfaces and Headers, Issue 5 (XSH)

Two general changes were made to System Interfaces and Headers, Issue 4, Version 2 (XSH):

• Use of the typeintfor return values, arguments, and structure members.
  Several functions using the typeintfor return values, arguments, or structure members are not able to represent 64-bit values correctly on architectures implementing an LP64 data model. Where alternate functions were available which do not have this limitation, the functions were marked LEGACY and the alternate functions noted in the Application Usage section. Where no alternative function was available, the types were changed in a data model-neutral manner to overcome this limitation.
• size_t versus ssize_t.
  Several functions have a parameter declared to besize_twhere the parameter specifies the length of an object to manipulate, and returns the portion of the length of the object processed in a typessize_t. The typessize_tis required so that a negative return value can be used to indicate an error. However, in these functions it is possible for the return value to exceed the range of the typessize_t(sincesize_thas a larger range of positive values thanssize_t). Some functions, such as_mq_receive()_ ,msgrcv() ,read() ,strfmon() , and_write()_ , resolve this conflict by restricting the object size in the description section. For example, the description section for the_rea()_d function states: "If the value of_nbyte_is greater than {SSIZE_MAX}, the result is implementation-dependent."

The following were the detailed changes:

• getdtablesize()
  The_getdtablesize()_function returns the size of the file descriptor table. This is equivalent to_getrlimit()_with the RLIMIT_NOFILE option. Whereas the_getrlimit()_function returns a value of typerlim_t. This function, returning anint, may have problems representing appropriate values in the future. A note about this was added to the Application Usage section, and the function marked LEGACY, with the recommendation that applications should use the_getrlimit()_function instead.
• getpagesize()
  The_getpagesize()function returns the current page size. It is equivalent to_sysconf(_SC_PAGE_SIZE) and_sysconf_(_SC_PAGESIZE). This function, returning anint, may have problems representing appropriate values on non-32-bit platforms. Also, the behavior is not specified for this function on systems that support variable size pages. On variable page size systems, a page can be extremely large (theoretically, up to the size of memory). This allows very efficient address translations for large segments of memory that have common page attributes. A note about this has been added to the Application Usage section, and the function marked LEGACY, with the recommendation that applications should use the_sysconf()_function instead.
• readlink()
  The_readlink()_function returns the size of the information that it reads as a typeint, but the size of the buffer area is specified by asize_t. This function is specified in the IEEE PASC P1003.1a draft standard, and the return value may change in a future version of the Single UNIX Specification to reflect the final POSIX.1a standard.
• sbrk()
  The parameter to the_sbrk()_function is a typeintdefining the number of bytes by which to change the break value. This function may not be able to address the full memory range in the future for certain data models. A new type has been introduced to be used in place of the typeint. This is theintptr_ttype which is an abstract data type equating to a signed integral type large enough to hold any pointer. This new type is one of a new set of types introduced in a new header_inttypes.h_to address the issues of data sizes for specific types.
• inttypes.h
  The_inttypes.h_header is a new header in the Single UNIX Specification, Version 2 and includes definitions for at least the following types:
  int16_t
  16-bit signed integral type.
  int32_t
  32-bit signed integral type.
  int64_t
  64-bit signed integral type.
  uint16_t
  16-bit unsigned integral type.
  uint32_t
  32-bit unsigned integral type.
  uint64_t
  64-bit unsigned integral type.
  intptr_t
  Signed integral type large enough to hold any pointer.
  uintptr_t
  Unsigned integral type large enough to hold any pointer.
• sys/shm.h
  The element_shm_segsz_of structureshmid_ds, specifying the size of a memory segment was of typeint. This has been changed to typesize_t.
• sys/stat.h_and_sys/statvfs.h
  The element_st_blocks_of the structurestatwas changed to the new abstractblkcnt_ttype.
  The elements_f_blocks_,f_bfree, and_f_bavail_of the structurestatvfswere changed to the new abstractfsblkcnt_ttype.
  The elements_f_files_,f_ffree, and_f_favail_of the structurestatvfswere changed to the new abstractfsfilcnt_ttype.
  To support the above changes, the following definitions were added to_sys/types.h_ :
  blkcnt_t
  A signed arithmetic type, used for file block counts.
  fsblkcnt_t
  An arithmetic type, used for filesystem block counts.
  fsfilcnt_t
  An arithmetic type, used for file serial numbers.
• sys/time.h
  The_tv_usec_element of thetimevalstructure was of typelong. This has been changed to use a new abstract data type for signed integral time values, known assuseconds_t.suseconds_twas added to sys/types.h .
• msgrcv()
  In XSH, Issue 4, Version 2,_msgrcv()_returns the size of the message received as an integer value, but the size of the message area is specified by asize_t. On 64-bit systems wheresize_tmay be a different data type toint, this will cause problems. XSH, Issue 5 addresses this problem by changing the type of the return value frominttossize_t, and adding a warning to the Description about values of_msgsz_larger the {SSIZE_MAX}.
• sysconf()and_unistd.h
  There is now a way to find out the data model supported by the platform. This can be queried at compile time, using the constants defined in_unistd.h , or at run time using the_sysconf()_function.
  The following symbolic constants are defined to have the value -1 if the implementation never provides the feature, and to have a value other than -1 if the implementation always provides the feature. If these are undefined, the_sysconf()_function can be used to determine whether the feature is provided for a particular invocation of the application.
  _XBS5_ILP32_OFF32
  Implementation provides a C-language compilation environment with 32-bitint,long,pointer, andoff_ttypes.
  _XBS5_ILP32_OFFBIG
  Implementation provides a C-language compilation environment with 32-bitint,long, andpointertypes, and anoff_ttype using at least 64 bits.
  _XBS5_LP64_OFF64
  Implementation provides a C-language compilation environment with 32-bitintand 64-bitlong,pointer, andoff_ttypes.
  _XBS5_LPBIG_OFFBIG
  Implementation provides a C-language compilation environment with aninttype using at least 32 bits andlong,pointer, andoff_ttypes, using at least 64 bits.

Commands and Utilities, Issue 5 (XCU)

A new section of text was added to the end of the first paragraph of Section 1.9, Utility Description Defaults, to align with requirements in POSIX.2, and restates that integer variables and constants used by utilities are permitted to be 64-bit values.

Programming Environments

The_c89_reference page has some new text describing programming environments. All conforming implementations must support one of the following programming environments by default. Applications can use the_sysconf()_function or the_getconf_utility to determine which programming environments the implementation supports.

The following table describes the supported programming environments.

The_c89_reference page also has text describing new support in_getconf_and_sysconf()_to determine configuration strings for C compiler flags, linker/loader flags, and libraries for each supported environment.

When an application wishes to use a specific programming environment rather than an implementation's default programming environment while compiling, the application must first verify that the implementation supports the desired environment. If the desired programming environment is supported, the application can then invoke_c89_with the appropriate C compiler flags as the first options for the compile, the appropriate linker/loader flags after any other options but before any operands, and the appropriate libraries at the end of the operands.

The following table shows the various options available:

Porting Issues

Porting an application to a 64-bit UNIX system can be accomplished with a minimal amount of effort if the application was developed using good modern software engineering practices such as:

• ISO C function prototypes
• consistent and careful use of data types
• all declarations are in headers.

First of all, determine which data model is available on the platform you are porting to. The data model you are porting to will have a major impact on the amount of work required to achieve a successful port.

Then take the time to create and use ISO C function prototypes if they are absent from the source code. Unfortunately large quantities of perfectly good legacy code developed in the days before portability was a major issue may not have function prototypes. Fortunately many compilers have an option to generate ISO C function prototypes.

The remainder of this article assumes that you are porting to an LP64 platform since this is the data model of choice amongst major vendors, but the issues raised are equally valid on some or all of the other 64-bit data models.

General

Use utilities such as_grep_to locate and check all instances of the following:

• Shift and complement operators; that is, "<<", ">>", "~". If used withlong,**".**add "L" to value shifted to avoid an incorrect result.
• Addresses of "&". Make sure they are not being stored in anint.
• Declarations of typelong. Many of these can be converted to typeintto save space. This is particularly true for network code.
• The functions_lseek()_ ,fseek() ,ftell() ,fgetpos() , and so on. Use eitheroff_torfpos_tas appropriate for offset arguments. Do not useintorlongto store file offsets.
• All (int *) and (long *) casts.
• Use of (char *) 0 for zero or (char *) comparisons. Use NULL instead.
• Hard-coded byte counts or memory sizes. These will be wrong if they assumelongs orpointers are 32 bits. Applications should use the_sizeof()_operator to avoid such problems.

Declarations

To enable application code to work on both 32-bit and 64-bit platforms, check allintandlongdeclarations. Declare integer constants using "L" or "U" as appropriate. Ensure anunsigned intis used where appropriate to prevent sign extension. If you have specific variables that need to be 32 bits on both platforms, define the type to beint. If the variable should be 32 bits on an ILP32 platform and 64 bits on an LP64 platform, define the variables to belong.

Declare numeric variables asintorlongfor alignment and performance. Don't worry about trying to save bytes by usingcharorshort. Remember that if the type specifier is missing from a declaration, it defaults to anint. Declare character pointers and character bytes asunsignedto avoid sign extension problems with 8-bit characters.

Assignments and Function Parameters

All assignments require checking. Sincepointer,int, andlongare no longer the same size on LP64 platforms, problems may arise depending on how the variables are assigned and used within an application.

Do not useintandlonginterchangeably because of the possible truncation of significant digits, as shown in the following example:

int iv; long lv; iv = lv;

Do not useintto store a pointer. The following example works on an ILP32 platform but fails on an LP64 platform because a 32-bit integer cannot hold a 64-bit pointer:

unsigned int i, *p;

i = (unsigned) p;

The converse of the above example is sign extension:

int *p; int i;

p = (int *)i;

Do not passlongarguments to functions expectingintarguments. Avoid assignments similar to the following:

int foo(int);

int iv; long lv; iv = foo( lv );

Do not freely exchangepointers andints. Assigning a pointer to anint, assigning back to apointer, and dereferencing the pointer may result in a segmentation fault. Avoid assignments similar to the following example:

int iv; char *buffer;

buffer = (char *) malloc((sizet)MAXLINE);

iv = (int) buffer; buffer = (char *) iv;

Do not pass a pointer to a function expecting anintas this will result in lost information. For example, avoid assignments similar to the following:

void f(); char *cp;

f(cp);

Use of ISO C function prototypes should avoid this problem. Use thevoid*type if you need to use a generic pointer type. This is preferable to converting apointerto typelong.

Examine all assignments of alongto adoubleas this can result in a loss of accuracy. On an ILP32 platform, an application can assume that adoublecontains an exact representation of any value stored in along(or apointer). On LP64 platforms this is no longer a valid assumption.

External Interfaces

An external interface mismatch occurs when an external interface requires data in a particular size or layout, but the data is not supplied in the correct format.

For example, an external interface may expect a 64-bit quantity, but receive instead a 32-bit quantity. Another example is an external structure which expects a pointer to a structure with 2ints (8 bytes) but instead receives a pointer to a structure with anintand along(16 bytes, 12 of data, 4 of alignment padding). External interface mismatching is a major cause of porting problems.

Format Strings

The function_printf()_and related functions can be a major source of problems. For example, on 32-bit platforms, using "%d" to print either anintorlongwill usually work, but on LP64 platforms "%ld" must be used to print along. Use the modifier "l" with the d, u, o, and x conversion characters to specify assignment of typelongorunsigned long. When printing a pointer, use "%p". If you wish to print the pointer as a specific representation, the pointer should be cast to an appropriate integer type before using the desired format specifier. For example, to print a pointer as aunsigned longdecimal number, use %lu:

char *p;

printf( "%p %lu\n", (void *)p, (unsigned long)p );

As a rule, to print an integer of arbitrary size, cast the integer tolongorunsigned longand use the "%ld" conversion character.

Constants

The results of arithmetic operations on a 64-bit platform can differ from those obtained using the same code on a 32-bit platform. Differing results are often caused by sign extension problems. These are generally the result of mixingsignedandunsignedtypes and the use of hexadecimal constants. Consider the following code example:

long lv = 0xFFFFFFFF;

if ( lv < 0 ) {

On an ILP32 platform,_lv_is interpreted as -1 and the_if_condition succeeds. On an LP64 platform_lv_is interpreted as 4294967295 and the if condition fails.

Pointers

On ILP32 platforms, anintand apointerare the same size (32 bits) and application code can generally use them interchangeably. For example, a structure could contain a field declared as anint, and most of the time contain aninteger, but occasionally be used to store apointer.

Another example, which most 32-bitintutilities will not catch, is the following:

int iv, *pv;

iv = (int) pv; pv = (int *) iv;

This code fails on an LP64 platform. Not only do you lose the high 4 bytes of "p", but by default these high bytes are significant.

Sizeof()

On ILP32 platformssizeof(int) =sizeof(long) =sizeof(ptr *). Using the wrong_sizeof()_operand does not cause a problem. On LP64 platforms, however, using the wrong_sizeof()_will almost certainly cause a problem. For example, the following 32-bit code which copies an array ofpointers toints:

memcpy((char *)dest, (char *)src, number * sizeof(int))

must be changed to usesizeof(int *):

memcpy((char *)dest, (char *)src, number * sizeof(int *))

on an LP64 platform.

Note that the result of the_sizeof()_operation is typesize_twhich is anunsigned longon LP64 platforms.

Structures and Unions

The size of structures and unions on 64-bit platforms can be different from those on 32-bit platforms. For example, on ILP32 platforms the size of the following structure is 8 bytes:

struct Node { struct Node *left; struct Node *right; }

but on an LP64 platform its size is 16 bytes.

If you are sharing data defined in structures between 32-bit and 64-bit platforms, be careful about usinglongs andpointers as members of shared structures. These data types introduce sizes that are not generally available on 32-bit platforms. Avoid storing structures with pointers in data files. This code then becomes non-portable between 32-bit and 64-bit platforms.

To increase the portability of your code, usetypedef'd types for the fields in structures to set up the types as appropriate for the platform, and use the_sizeof()_operator to determine the size of a structure. If necessary, use the**#pragmapack statement to avoid compiler structure padding. [Note:**This is not portable and is not a general solution.] This is important if data alignment cannot change (network packets, and so on).

Structures are aligned according to the strictest aligned member. Padding may be added to ensure proper alignment. This padding may be added within the structure, or at the end of the structure to terminate the structure on the same alignment boundary which it started.

Problems can occur when the use of a union is based on an implicit assumption, such as the size of member types.

Consider the following code fragment which works on ILP32 platforms. The code assumes that an array of twounsigned longoverlays a double.

union doubleunion { double d; unsigned long ul[2]; };

To work on an LP64 platform,_ul_must be changed to anunsigned inttype:

union doubleunion { double d; unsigned int ul[2] };

This problem also occurs when building unions betweenints andpointers since they are not the same size on LP64 platforms.

Beware of all aliasing which is different multiple definitions of the same data. For example, assume the following two structures refer to the same data in different ways:

struct node { int srcaddr, dstaddr; char *name; }

struct node { struct node *src, *dst; char *name; }

This works on an ILP32 platform, but fails on an LP64 platform. The two structure definitions should be replaced with a union declaration to ensure portability.

More Information

This article is derived from The Open Group Source Book, "Go Solo 2 - The Authorized Guide to Version 2 of the Single UNIX Specification". This is published herein with permission of The Open Group. More information on the Single UNIX Specification, Version 2 can be obtained from the following sources:

• The online version of the Single UNIX Specification can be found at the URL http://www.UNIX-systems.org/online.html.
• The Open Group Source Book "Go Solo 2 - The Authorized Guide to Version 2 of the Single UNIX Specification", 600 pages, ISBN 0-13-575689-8. This book provides complete information on what's new in Version 2 , with technical papers written by members of the working groups that developed the specifications , and a CD-ROM containing the complete 3000 page specification in both HTML and PDF formats (including PDF reader software). For more information on the book, see URL http://www.UNIX-systems.org/gosolo2 .
• Additional information on the Single UNIX Specification can be obtained at The Open Group world wide web site, see the URLhttp://www.UNIX-systems.org .