64bit.html

unix 下的C开发手册,还用详细的例程。

<I>int iv;
long lv;
iv = lv;</I>

</pre>
<p>
Do not use
<B>int</B>
to 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:
<pre>

<I>unsigned int i, *p;
<p>
i = (unsigned) p;</I>

</pre>
<p>
The converse of the above example is sign extension:
<pre>

<I>int *p;
int i;
<p>
p = (int *)i;</I>

</pre>
<p>
Do not pass
<B>long</B>
arguments to functions expecting
<B>int</B>
arguments.
Avoid assignments similar to the following:
<pre>

<I>int foo(int);
<p>
int iv;
long lv;
iv = foo( lv );</I>

</pre>
<p>
Do not freely exchange
<B>pointer</B>s
and
<B>int</B>s.
Assigning a pointer to an
<B>int</B>,
assigning back to a
<B>pointer</B>,
and dereferencing the pointer may result in a segmentation fault.
Avoid assignments similar to the following example:
<pre>

<I>int iv;
char *buffer;
<p>
buffer = (char *) malloc((size_t)MAX_LINE);
<p>
iv = (int) buffer;
buffer = (char *) iv;</I>

</pre>
<p>
Do not pass a pointer to a function expecting an
<B>int</B>
as this will result in lost information.
For example, avoid assignments similar to the following:
<pre>

<I>void f();
char *cp;
<p>
f(cp);</I>

</pre>
<p>
Use of ISO&nbsp;C function prototypes should avoid this problem.
Use the
<B>void*</B>
type if you need to use a generic pointer type.
This is preferable to converting a
<B>pointer</B>
to type
<B>long</B>.
<p>
Examine all assignments of a
<B>long</B>
to a
<B>double</B>
as this can result in a loss of accuracy.
On an ILP32 platform, an application can assume that a
<B>double</B>
contains an exact representation of any value stored in a
<B>long</B>
(or a
<B>pointer</B>).
On LP64 platforms this is no longer a valid assumption.
<h4>External Interfaces</h4>
<p>
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.
<p>
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 2
<B>int</B>s
(8 bytes) but instead receives a pointer to a structure with an
<B>int</B>
and a
<B>long</B>
(16 bytes, 12 of data, 4 of alignment padding).
External interface mismatching is a major cause of porting problems.
<h4>Format Strings</h4>
<p>
The function
<I>printf()</I>
and related functions can be a major source of problems.
For example, on 32-bit platforms, using &quot;%d&quot; to print either an
<B>int</B>
or
<B>long</B>
will usually work,
but on LP64 platforms &quot;%ld&quot; must be used to print a
<B>long</B>.
Use the modifier &quot;l&quot; with the d, u, o, and x conversion characters
to specify assignment of type
<B>long</B>
or
<B>unsigned long</B>.
When printing a pointer, use &quot;%p&quot;.
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 a
<B>unsigned long</B>
decimal number, use %lu:
<p>
<I>char *p;</I>
<p>
<I>printf( "%p %lu\n", (void *)p, (unsigned long)p );</I>
<p>
As a rule, to print an integer of arbitrary size, cast the integer to
<B>long</B>
or
<B>unsigned long</B>
and use the &quot;%ld&quot; conversion character.
<h4>Constants</h4>
<p>
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 mixing
<B>signed</B>
and
<B>unsigned</B>
types and the use of hexadecimal constants.
Consider the following code example:
<pre>

<I>long lv = 0xFFFFFFFF;
<p>
if ( lv &lt; 0 ) {</I>

</pre>
On an ILP32 platform,
<I>lv</I>
is interpreted as -1 and the
<I>if</I>
condition succeeds.
On an LP64 platform
<I>lv</I>
is interpreted as 4294967295 and the if condition fails.
<h4>Pointers</h4>
<p>
On ILP32 platforms, an
<B>int</B>
and a
<B>pointer</B>
are the same size (32 bits) and application code can generally use
them interchangeably.
For example, a structure could contain a field declared as an
<B>int</B>,
and most of the time contain an
<B>integer</B>,
but occasionally be used to store a
<B>pointer</B>.
<p>
Another example, which most 32-bit
<B>int</B>
utilities will not catch, is the following:
<pre>

<I>int iv, *pv;
<p>
iv = (int) pv;
pv = (int *) iv;</I>

</pre>
<p>
This code fails on an LP64 platform.
Not only do you lose the high 4 bytes of &quot;p&quot;, but by default these high
bytes are significant.
<h4>Sizeof()</h4>
<p>
On ILP32 platforms
<B>sizeof</B>(<B>int</B>)
=
<B>sizeof</B>(<B>long</B>)
=
<B>sizeof</B>(<B>ptr *</B>).
Using the wrong
<I>sizeof()</I>
operand does not cause a problem.
On LP64 platforms, however, using the wrong
<I>sizeof()</I>
will almost certainly cause a problem.
For example, the following 32-bit code which copies an array of
<B>pointer</B>s
to
<B>int</B>s:
<p>
<I>memcpy((char *)dest, (char *)src, number * sizeof(int))</I>
<p>
must be changed to use
<B>sizeof</B>(<B>int *</B>):
<p>
<I>memcpy((char *)dest, (char *)src, number * sizeof(int *))</I>
<p>
on an LP64 platform.
<p>
Note that the result of the
<I>sizeof()</I>
operation is type
<B>size_t</B>
which is an
<B>unsigned long</B>
on LP64 platforms.
<h4>Structures and Unions</h4>
<p>
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:
<pre>

<I>struct Node {
    struct Node *left;
    struct Node *right;
}</I>

</pre>
<p>
but on an LP64 platform its size is 16 bytes.
<p>
If you are sharing data defined in structures between 32-bit
and 64-bit platforms, be careful about using
<B>long</B>s
and
<B>pointer</B>s
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.
<p>
To increase the portability of your code, use
<B>typedef</B>'d
types for the fields in structures to set up the types as
appropriate for the platform, and use the
<I>sizeof()</I>
operator to determine the size of a structure.
If necessary, use the
<B>#pragma</B>
pack statement to avoid compiler structure padding.
[<small><B>Note:</B>This is not portable and is not a general solution.
</small>]
This is important if data alignment cannot change (network packets,
and so on).
<p>
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.
<p>
Problems can occur when the use of a union is based on an implicit
assumption, such as the size of member types.
<p>
Consider the following code fragment which works on ILP32 platforms.
The code assumes that an array of two
<B>unsigned long</B>
overlays a double.
<pre>

<I>union double_union {
    double d;
    unsigned long ul[2];
};</I>

</pre>
<p>
To work on an LP64 platform,
<I>ul</I>
must be changed to an
<B>unsigned int</B>
type:
<pre>

<I>union double_union {
    double d;
    unsigned int ul[2]
};</I>

</pre>
This problem also occurs when building unions between
<B>int</B>s
and
<B>pointer</B>s
since they are not the same size on LP64 platforms.
<p>
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:
<pre>

<I>struct node {
    int src_addr, dst_addr;
    char *name;
}
<p>
struct node {
    struct node *src, *dst;
    char *name;
}</I>
</pre>

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

<h3>More Information</h3>
<p>
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:
<ul>
<p>
<li>
The online version of the Single UNIX Specification can be
found at the
URL 
<a href="http://www.UNIX-systems.org/online.html">http://www.UNIX-systems.org/online.html</a>.
<p>
<li>
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 
<a href="http://www.unix-systems.org/gosolo2">http://www.UNIX-systems.org/gosolo2</a> .
<p>
<li>
Additional information on the Single UNIX Specification can be
obtained at The Open Group world wide web site, see the URL
<a href="http://www.UNIX-systems.org/">http://www.UNIX-systems.org</a> . 
<p>
</ul>
<p>
<HR>
<FONT  SIZE=2 FACE="ARIAL">
<P>
<em>UNIX is a registered trademark of The Open Group</em>.
<P>
Copyright &copy; 1997-1999 , The Open Group.
</CENTER>
</FONT>
</BODY>
</HTMl>