Converting 32-bit Applications Into 64-bit Applications: Things to Consider

﹏ヽ暗。殇╰゛Y 2022-06-05 09:20 220阅读 0赞

# Converting 32-bit Applications Into 64-bit Applications: Things to Consider #

<table style="color:rgb(0,0,0); font-family:Arial,Helvetica,FreeSans,Luxi-sans,'Nimbus Sans L',sans-serif; font-size:12px"> 
 <tbody> 
  <tr> 
   <td><a rel="nofollow"></a> 
    <table> 
     <tbody> 
      <tr> 
       <td style="font-size:11px"><em></em></td> 
       <td>&nbsp;</td> 
       <td align="right"> 
        <div style="font-size:11px; padding:0px"> 
         <table> 
          <tbody> 
           <tr> 
            <td align="right"></td> 
            <td style="font-size:11px"><a href="http://developers.sun.com/jsp_utils/PrintPage.jsp" style="color:rgb(0,0,0); text-decoration:none" rel="nofollow"><img src="http://developers.sun.com/im/ic_print.gif" width="14" height="12" alt="Print-friendly Version" style="border:none">Print-friendly Version</a></td> 
           </tr> 
          </tbody> 
         </table> 
        </div> </td> 
      </tr> 
     </tbody> 
    </table> 
    <table> 
     <tbody> 
      <tr> 
       <td style="font-size:11px"><em>By The Sun Studio Team, January 2005</em></td> 
       <td>&nbsp;</td> 
       <td align="right"> 
        <div style="font-size:11px; padding:0px"> 
         <table> 
          <tbody> 
           <tr></tr> 
          </tbody> 
         </table> 
        </div> </td> 
      </tr> 
     </tbody> 
    </table> 
    <div style="padding:3px 0px 6px"> 
     <table style="background-color:rgb(231,231,231)"> 
      <tbody> 
       <tr> 
        <td><img src="http://developers.sun.com/im/a.gif" width="1" height="4" alt=" " style="border:none; height:2px"></td> 
       </tr> 
      </tbody> 
     </table> 
    </div> 
    <table style="background-color:rgb(227,227,227)"> 
     <tbody> 
      <tr> 
       <td>The principal cause of problems when converting 32-bit applications to 64-bit applications is the change in size of the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;type with respect to the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;and pointer types. When converting 32-bit programs to 64-bit programs, only&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;types and pointer types change in size from 32 bits to 64 bits; integers of type&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;stay at 32 bits in size. This can cause trouble with data truncation when assigning pointer or&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;types to&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;types. Also, problems with sign extension can occur when assigning expressions using types shorter than the size of an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;to an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code>&nbsp;or a pointer. This article discusses how to avoid or eliminate these problems.</td> 
      </tr> 
     </tbody> 
    </table> <span style="font-size:8px!important">&nbsp;</span><br> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Consider the Differences Between the 32-bit and 64-bit Data Models</h2> <p style="margin-top:2px; margin-bottom:17px">The biggest difference between the 32-bit and the 64-bit compilation environments is the change in data-type models. The C data-type model for 32-bit applications is the ILP32 model, so named because the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;and&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;types, and pointers, are 32-bit data types. The data-type model for 64-bit applications is the LP64 data model, so named because&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;and pointer types grow to 64 bits. The remaining C integer types and the floating-point types are the same in both data-type models.</p> <p style="margin-top:3px; margin-bottom:17px">It is not unusual for current 32-bit applications to assume that the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;type,&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;type, and pointers are the same size. Because the size of&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;and&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">pointer</code>&nbsp;change in the LP64 data model, this change alone is the principal cause of ILP32-to-LP64 conversion problems.</p> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Use the&nbsp;lint&nbsp;Utility to Detect Problems with 64-bit&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;and Pointer Types</h2> <p style="margin-top:2px; margin-bottom:17px">Use&nbsp;lint&nbsp;to check code that is written for both the 32-bit and the 64-bit compilation environment. Specify the&nbsp;-errchk=longptr64&nbsp;option to generate LP64 warnings. Also use the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">-errchk=longptr64</code>&nbsp;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&nbsp;-errchk=longptr64&nbsp;flag checks assignments of pointer expressions and long integer expressions to plain integers, even when explicit casts are used.</p> <p style="margin-top:3px; margin-bottom:17px">Use the&nbsp;-errchk=longptr64,signext&nbsp;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&nbsp;-xarch=v9&nbsp;option of&nbsp;lint&nbsp;when you want to check code that you intend to run in the Solaris 64-bit SPARC compilation environment only. Use&nbsp;-xarch=amd64&nbsp;when you want to check code you intend to run in the x86 64-bit environment.</p> <p style="margin-top:3px; margin-bottom:17px">When lint generates warnings, it prints the line number of the offending code, a message that describes the problem, and whether or not 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 pre-existing problems between 32-bit and smaller types.</p> <p style="margin-top:3px; margin-bottom:17px">You can suppress the warning for a given line of code by placing a comment of the form&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">"NOTE(LINTED(&lt;optional message&gt;))"</code>&nbsp;on the previous line. This is useful when you want lint to ignore certain lines of code such as casts and assignments. Exercise extreme care when you use the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">"NOTE(LINTED(&lt;optional message&gt;))"</code>&nbsp;comment because it can mask real problems. When you use&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">NOTE</code>, also include&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">#include&lt;note.h&gt;</code>. Refer to the&nbsp;lint man&nbsp;page for more information.</p> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Check for Changes of Pointer Size With Respect to the Size of Plain Integers</h2> <p style="margin-top:2px; margin-bottom:17px">Since plain integers and pointers are the same size in the ILP32 compilation environment, 32-bit code commonly relies on this assumption. Pointers are often cast to&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;or&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned int</code>&nbsp;for address arithmetic. You can cast your pointers to&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code>&nbsp;because&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;and pointer types are the same size in both ILP32 and LP64 data-type models. However, rather than explicitly using<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code>, use&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">uintptr_t</code>&nbsp;instead because it expresses your intent more closely and makes the code more portable, insulating it against future changes. To use the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">uintptr_t</code>&nbsp;and&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">intptr_t</code>you need to&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">#include &lt;inttypes.h&gt;</code>.</p> <p style="margin-top:3px; margin-bottom:17px">Consider the following example:</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">char *p;<br> p = (char *) ((int)p &amp; PAGEOFFSET);<br> % cc ..<br> warning: conversion of pointer loses bits</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <p style="margin-top:3px; margin-bottom:17px">The following version will function correctly when compiled to both 32-bit and 64-bit targets:</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">char *p;<br> p = (char *) ((uintptr_t)p &amp; PAGEOFFSET);<br> </code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Check for Changes in Size of&nbsp;Long Integers With Respect to the Size of Plain Integers</h2> <p style="margin-top:2px; margin-bottom:17px">Because integers and longs are never really distinguished in the ILP32 data-type model, your existing code probably uses them indiscriminately. Modify any code that uses integers and longs interchangeably so it conforms to the requirements of both the ILP32 and LP64 data-type models. While an integer and a long are both 32-bits in the ILP32 data-type model, a long is 64 bits in the LP64 data-type model.</p> <p style="margin-top:3px; margin-bottom:17px">Consider the following example:</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int waiting;<br> long w_io;<br> long w_swap;<br> ...<br> waiting = w_io + w_swap;<br> <br> % cc<br> warning: assignment of 64-bit integer to 32-bit integer</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Check for Sign Extensions</h2> <p style="margin-top:2px; margin-bottom:17px">Sign extension is a common problem when you convert to the 64-bit compilation environment because the type conversion and promotion rules are somewhat obscure. To prevent sign-extension problems, use explicit casting to achieve the intended results.</p> <p style="margin-top:3px; margin-bottom:17px">To understand why sign extension occurs, it helps to understand the conversion rules for ISO C. The conversion rules that seem to cause the most sign extension problems between the 32-bit and the 64-bit compilation environment come into effect during the following operations:</p> 
    <ul style="margin-left:13px; padding-left:0px"> 
     <li style="margin-left:13px; padding-left:0px"><strong>Integral promotion</strong> <p style="margin-top:3px; margin-bottom:17px">You can use a char, short, enumerated type, or bit-field, whether signed or unsigned, in any expression that calls for an integer. If an integer can hold all possible values of the original type, the value is converted to an integer; otherwise, the value is converted to an unsigned integer.</p> </li> 
     <li style="margin-left:13px; padding-left:0px"><strong>Conversion between signed and unsigned integers</strong> <p style="margin-top:3px; margin-bottom:17px">When an integer with a negative sign is promoted to an unsigned integer of the same or larger type, it is first promoted to the signed equivalent of the larger type, then converted to the unsigned value.</p> </li> 
    </ul> <p style="margin-top:3px; margin-bottom:17px">When the following example is compiled as a 64-bit program, the addr variable becomes sign-extended, even though both addr and a.base are unsigned types.</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">%cat test.c<br> struct foo { <br> &nbsp;&nbsp;unsigned int base:19, rehash:13;<br> };<br> main(int argc, char *argv[])<br> { <br> &nbsp;&nbsp;struct foo a;<br> &nbsp;&nbsp;unsigned long addr;<br> &nbsp;&nbsp;a.base = 0x40000;<br> &nbsp;&nbsp;addr = a.base &lt;&lt; 13; /* Sign extension here! */<br> &nbsp;&nbsp;printf("addr 0x%lx\n", addr);<br> &nbsp;&nbsp;addr = (unsigned int)(a.base &lt;&lt; 13); /* No sign extension here! */<br> &nbsp;&nbsp;printf("addr 0x%lx\n", addr);<br> }</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <p style="margin-top:3px; margin-bottom:17px">This sign extension occurs because the conversion rules are applied as follows:</p> 
    <ul style="margin-left:13px; padding-left:0px"> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">The structure member a.base</code>&nbsp;is converted from an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned int</code>&nbsp;bit field to an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;because of the integral promotion rule. In other words, because the unsigned 19-bit field fits within a 32-bit integer, the bit field is promoted to an integer rather than an unsigned integer. Thus, the expression&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">a.base &lt;&lt; 13</code>&nbsp;is of type&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>. If the result were assigned to an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned int</code>, this would not matter because no sign extension has yet occurred.<br> </li> 
     <li style="margin-left:13px; padding-left:0px">The expression&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">a.base &lt;&lt; 13</code>&nbsp;is of type&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>, but it is converted to a&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;and then to an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code>&nbsp;before being assigned to&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">addr</code>, because of signed and unsigned integer promotion rules. The sign extension occurs when performing the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;to&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;conversion.</li> 
    </ul> <p style="margin-top:3px; margin-bottom:17px">Thus, when compiled as a 64-bit program, the result is as follows:</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">% cc -o test64 -xarch=v9 test.c<br> % ./test64<br> addr 0xffffffff80000000<br> addr 0x80000000<br> %</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <p style="margin-top:3px; margin-bottom:17px">&nbsp;When compiled as a 32-bit program, the size of an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code>&nbsp;is the same as the size of an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>, so there is no sign extension.</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">% cc -o test test.c<br> % ./test<br> addr 0x80000000<br> addr 0x80000000<br> %</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Check Structure Packing</h2> <p style="margin-top:2px; margin-bottom:17px">Check the internal data structures in an applications for holes; that is, extra padding appearing between fields in the structure to meet alignment requirements. This extra padding is allocated when<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;or pointer fields grow to 64 bits for the LP64 data-type model, and appear after an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;that remains at 32 bits in size. Since&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;and pointer types are 64-bit aligned in the LP64 data-type model, padding appears between the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;and&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;or pointer type. In the following example, member&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">p</code>&nbsp;is 64-bit aligned, and so padding appears between the member&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">k</code>&nbsp;and member&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">p</code>.</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">struct bar { <br> &nbsp;&nbsp;int i;<br> &nbsp;&nbsp;long j;<br> &nbsp;&nbsp;int k;<br> &nbsp;&nbsp;char *p;<br> }; /* sizeof (struct bar) = 32 bytes */</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <p style="margin-top:3px; margin-bottom:17px">Also, structures are aligned to the size of the largest member within them. Thus, in the above structure, padding appears between member&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">i</code>&nbsp;and member&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">j</code>.</p> <p style="margin-top:3px; margin-bottom:17px">When you repack a structure, follow the simple rule of moving the long and pointer fields to the beginning of the structure. Consider the following structure definition:</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">struct bar { <br> &nbsp;&nbsp;char *p;<br> &nbsp;&nbsp;long j;<br> &nbsp;&nbsp;int i;<br> &nbsp;&nbsp;int k;<br> }; /* sizeof (struct bar) = 24 bytes */</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Check for Unbalanced Size of Union Members</h2> <p style="margin-top:2px; margin-bottom:17px">Be sure to check the members of unions because their fields can change size between the ILP32 and the LP64 data-type models, making the size of the members different. In the following union, member&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">_d</code>&nbsp;and member array&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">_l</code>&nbsp;are the same size in the ILP32 model, but different in the LP64 model because&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;types grow to 64 bits in the LP64 model, but&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">double</code>&nbsp;types do not.</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">typedef union { <br> &nbsp;&nbsp;double _d;<br> &nbsp;&nbsp;long _l[2];<br> } llx_</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <p style="margin-top:3px; margin-bottom:17px">The size of the members can be rebalanced by changing the type of the&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">_l</code>&nbsp;array member from type&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;to type&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>.</p> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Make Sure Constant Types are Used in Constant Expressions</h2> <p style="margin-top:2px; margin-bottom:17px">A lack of precision can cause the loss of data in some constant expressions. Be explicit when you specify the data types in your constant expression. Specify the type of each integer constant by adding some combination of { <code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">u,U,l,L</code>}. You can also use casts to specify the type of a constant expression. Consider the following example:</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int i = 32;<br> long j = 1 &lt;&lt; i; /* j will get 0 because RHS is integer expression */</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <p style="margin-top:3px; margin-bottom:17px">The above code can be made to work as intended, by appending the type to the constant,&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">1</code>, as follows:</p> 
    <blockquote> 
     <table> 
      <tbody> 
       <tr> 
        <td><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int i = 32;<br> long j = 1L &lt;&lt; i; /* now j will get 0x100000000, as intended */</code></td> 
       </tr> 
      </tbody> 
     </table> 
    </blockquote> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Check Format String Conversions</h2> <p style="margin-top:2px; margin-bottom:17px">Make sure the format strings for&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">printf</code>(3S),&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">sprintf</code>(3S),&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">scanf</code>(3S), and&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">sscanf</code>(3S) can accommodate long or pointer arguments. For pointer arguments, the conversion operation given in the format string should be&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">%p</code>&nbsp;to work in both the 32-bit and 64-bit compilation environments. For&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;arguments, the long size specification,&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">l</code>, should be prepended to the conversion operation character in the format string.</p> <p style="margin-top:3px; margin-bottom:17px">Also, check to be sure that buffers passed to the first argument in&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">sprintf</code>&nbsp;contain enough storage to accommodate the expanded number of digits used to convey long and pointer values. For example, a pointer is expressed by 8 hex digits in the ILP32 data model but expands to 16 in the LP64 data model.</p> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Type Returned by&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">sizeof()</code>&nbsp;Operator is an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code></h2> <p style="margin-top:2px; margin-bottom:17px">In the LP64 data-type model,&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">sizeof()</code>&nbsp;has the effective type of an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code>. If&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">sizeof()</code>&nbsp;is passed to a function expecting an argument of type&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>, or assigned or cast to an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>, the truncation could cause a loss of data. This is only likely to be problematic in large database programs containing extremely long arrays.</p> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Use Portable Data Types or Fixed Integer Types for Binary Interface Data</h2> <p style="margin-top:2px; margin-bottom:17px">For data structures that are shared between 32-bit and 64-bit versions of an application, stick with data types that have a common size between ILP32 and LP64 programs. Avoid using&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;data types and pointers. Also, avoid using derived data types that change in size between 32-bit and 64-bit applications. For example, the following types defined in&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">&lt;sys/types.h&gt;</code>&nbsp;change in size between the ILP32 and LP64 data models:</p> 
    <ul style="margin-left:13px; padding-left:0px"> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">clock_t</code>, which represents the system time in clock ticks</li> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">dev_t</code>, which is used for device numbers</li> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">off_t</code>, which is used for file sizes and offsets</li> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">ptrdiff_t</code>, which is the signed integral type for the result of subtracting two pointers</li> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">size_t</code>, which reflects the size, in bytes, of objects in memory</li> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">ssize_t</code>, which is used by functions that return a count of bytes or an error indication</li> 
     <li style="margin-left:13px; padding-left:0px"><code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">time_t</code>, which counts time in seconds</li> 
    </ul> <p style="margin-top:3px; margin-bottom:17px">Using the derived data types in&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">&lt;sys/types.h&gt;</code>&nbsp;is a good idea for internal data, because it helps to insulate the code from data-model changes. However, preccisely because the size of these types are prone to change with the data model, using them is not recommended in data that is shared between 32-bit and 64-bit applications, or in other situations where the data size must remain fixed. Nevertheless, as with the sizeof() operator discussed above, before making any changes to the code, consider whether the loss of precision will actually have any practical impact on the program.</p> <p style="margin-top:3px; margin-bottom:17px">For binary interface data, consider using the fixed-width integer types in &lt;inttypes.h&gt;. These types are good for explicit binary representations of the following:</p> 
    <ul style="margin-left:13px; padding-left:0px"> 
     <li style="margin-left:13px; padding-left:0px">Binary interface specifications</li> 
     <li style="margin-left:13px; padding-left:0px">On-disk data</li> 
     <li style="margin-left:13px; padding-left:0px">Over the data wire</li> 
     <li style="margin-left:13px; padding-left:0px">Hardware registers</li> 
     <li style="margin-left:13px; padding-left:0px">Binary data structures</li> 
    </ul> <br> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Check for Side Effects</h2> <p style="margin-top:2px; margin-bottom:17px">Be aware that a type change in one area can result in an unexpected 64-bit conversion in another area. For example, check all the callers of a function that previously returned an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;and now returns an&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">ssize_t</code>.</p> <h2 style="font-size:16px; margin:3px 0px 0px; padding:0px">Consider the Effect of&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;Arrays on Performance</h2> <p style="margin-top:2px; margin-bottom:17px">Large arrays of&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;or&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned long</code>&nbsp;types, can cause serious performance degradation in the LP64 data-type model as compared to arrays of&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;or&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">unsigned int</code>&nbsp;types. Large arrays of&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>types cause significantly more cache misses and consume more memory. Therefore, if&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;works just as well as&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>&nbsp;for the application purposes, it's better to use&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;rather than&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">long</code>. This is also an argument for using arrays of&nbsp;<code style="font-family:Monaco,Courier,'Courier New',monospace; color:rgb(68,68,68)">int</code>&nbsp;types instead of arrays of pointers. Some C applications suffer from serious performance degradation after conversion to the LP64 data-type model because they rely on many, large, arrays of pointers.</p> </td> 
  </tr> 
 </tbody> 
</table>