32 ビットから 64 ビットに変換アプリケーションを変換する際には、次の 2 つの基本的な問題があります。
データ型の整合性および異なるデータ型モデル
異なるデータ型モデルを使ったアプリケーション間の相互運用
通常は、できるだけ少ない数の #ifdef を使って 1 つのソースだけを管理する方が、複数のソースツリーを管理するよりも便利です。この章では、32 ビット環境と 64 ビット環境の両方で正しく動作するコードを書くためのガイドラインを示します。既存のコードを変換するのに必要なことは、再コンパイルして、64 ビットライブラリと再リンクするだけです。コードの変更が必要になった場合のために、変換を簡単に実行するためのツールについてもこの章で説明します。
すでに説明したように、32 ビットと 64 ビットの環境の大きな違いは、データ型モデルです。
32 ビットアプリケーションに使用される C データ型モデルは ILP32 で、int
、long
、およびポインタが 32 ビットであるためそのように呼ばれています。LP64 データ型モデルは、64 ビットアプリケーション用の C データ型モデルで、long
とポインタが 64 ビットに拡大されたためそのように呼ばれています。またこの LP64 データ型モデルは、業界の企業コンソーシアムで合意を得ています。C のデータ型の int
、 short
、 char
は、ILP32 データ型モデルと同じです。
次に示すように C の各整数データ型間の標準的な関係は変わりません。
sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)
表 4-1 に C の基本データ型と、それらの ILP32 および LP64 のデータ型モデルでのサイズをビット単位で示します。
表 4-1 データ型サイズ (単位 : ビット)
C データ型 |
ILP32 |
LP64 |
---|---|---|
|
8 |
変更なし |
|
16 |
変更なし |
|
32 |
変更なし |
|
32 |
64 |
|
64 |
変更なし |
|
32 |
64 |
|
32 |
変更なし |
|
32 |
変更なし |
|
64 |
変更なし |
|
128 |
変更なし |
32 ビットアプリケーションにおいては、しばしば int
、ポインタ、および long
が同じサイズであると仮定します。LP64 データ型モデルでは、long
とポインタのサイズが変更されています。この点から、32 ビットから 64 への変換の問題が発生する可能性があるということを認識する必要があります。
さらに意図するプログラム処理を示すためには、宣言とキャストが重要になります。たとえば、データ型が変わると式の評価方法が影響を受ける可能性があります。データ型のサイズが変更された場合には、C の標準の変換規則は影響を受けます。意図する内容を明確に示すには、定数の型を宣言する必要があります。キャストを式に入れることによって、式を確実に意図するように評価させることも必要です。これは特に、符号拡張の場合に当てはまります。この場合、目的の処理を正しく示すには、明示的にキャストする必要があります。
その他の問題としては、組み込みの C 演算子、書式文字列、アセンブリ言語、互換性、および相互運用性の問題があります。
この章の以降の節で、これらの問題の対処方法を紹介します。
これまで概要を示した問題の詳細な説明
コードを 32 ビットおよび 64 ビットに対して安全にするのに有用な、派生型とインクルードファイルの解説
コードを 64 ビット安全にするためのツールの紹介
32 ビットおよび 64 ビット環境間でコードを移植可能にするための一般的規則
32 ビットおよび 64 ビットコンパイルをサポートする単一ソースコードを書く際に役立つ、アプリケーション開発者向けの資源について説明します。
システム派生型は、コードを 32 ビットおよび 64 ビット安全にするのに便利です。これは、派生型自身が ILP32 および LP64 のデータ型モデルに対して安全である必要があるからです。一般に、変更を可能にするために派生型を使用しておくと便利です。後でデータ型モデルが変更された場合に、または異なるプラットフォームに移植する場合に、アプリケーションそのものではなく、システム派生型を変更するだけで済みます。
システムインクルードファイルの <sys/types.h> と <inttypes.h> には、アプリケーションを 32 ビットおよび 64 ビット安全にするために使用できる定数、マクロ、および派生型が格納されています。これらについての詳細は、このマニュアルでは説明していませんが、一部についてはこの章の以降の節および付録 A 「派生型の変更」 で説明しています。
<sys/types.h>
<sys/types.h> をインクルードするアプリケーションのソースファイルでは、<sys/isa_defs.h> をインクルードすることによって _LP64 と _ILP32 の定義を利用できるようになります。このヘッダーには、それぞれ必要に応じて適切な箇所で使用する基本派生型が多数含まれています。特に次のものは重要です。
clock_t
システムクロック時間を表わします。
dev_t
デバイス番号に使用される型です。
off_t
ファイルサイズとオフセット用に使用される型です。
ptrdiff_t
2 つのポインタの減算結果を示す符号付き整数型です。
size_t
メモリー内のオブジェクトのサイズ (バイト単位) 用に使用される型です。
ssize_t
バイト数またはエラーを返す関数によって使用される型です。
time_t
秒単位の時間用に使用される型です。
これらの型はすべて、ILP32 コンパイル環境では 32 ビット、LP64 コンパイル環境では 64 ビットになります。
これらの型のいくつかの使用方法については、「LP64 への変換のためのガイドライン」で詳しく説明しています。
<inttypes.h>
インクルードファイルの <inttypes.h> は、定数、マクロ、および派生型を定義するために Solaris 2.6 に追加されました。これによって、明示的にサイズを指定されたデータ項目について、コンパイル環境とは無関係にコードに互換性を持たせることができます。<inttypes.h> は、8 ビット、16 ビット、32 ビット、および 64 ビットのオブジェクトを操作するための機構が含まれてます。このインクルードファイルは、ANSI C の原案の一部で、ISO/JTC1/SC22/WG14 C 委員会による現在の ISO C 標準、つまり ISO/IEC 9899:1990 プログラミング言語 - C の改訂案を反映しています。
<inttypes.h> の主な機能は、次のとおりです。
固定幅整数型の集合
uintptr_t
とその他の有用なデータ型
定数マクロ
制限値
書式文字列マクロ
<inttypes.h> で提供される固定幅整数型には、int8_t、 int16_t、 int32_t、 int64_t、 uint8_t、 uint16_t、 uint32_t、 および uint64_t のような、符号付きおよび符号なし整数型があります。特定のビット数を格納できる最小の整数型として定義される派生型には、 int_least8_t、 int_least16_t、 int_least32_t、 int_least64_t、 uint_least8_t、 uint_least16_t、 uint_least32_t、 uint_least64_t があります。
これらの固定幅型を無制限に使用しないでください。たとえば、int
はこれまでと同様に、ループカウンタやファイル記述子などについて使用でき、long
は配列のインデックスに使用できます。固定幅型は、次に示すような明示的なバイナリ表現に使用してください。
ディスク上のデータ
送受信データ
ハードウェアレジスタ
バイナリインタフェース仕様
バイナリデータ構造
uintptr_t
とその他の有用なデータ型
<inttypes.h> によって提供されるその他の型として、ポインタを格納するために十分な領域が確保できる符号付きおよび符号なし整数型があります。これらの型には、intptr_t
と uintptr_t
があります。さらに、 intmax_t
および uintmax_t
という (ビット単位で) 最長の符号付きおよび符号なしデータ型があります。
uintptr_t
型をポインタ用の整数型として使用する方が、unsigned long
のような基本データ型を使用するよりも便利です。 unsigned long
は、IPL32 と LP64 データ型モデルの両方でポインタと同じサイズですが、 uintptr_t
を使用すると、uintptr_t
の定義を変更するだけで異なるデータ型モデルを使用できます。このため、他の多くのシステムに移植が可能となります。またこれによって、C プログラムコード中に意図する処理をより明確に記述することができます。
intptr_t
と uintptr_t
型は、アドレス計算をする際にポインタをキャストするのに非常に役に立ちます。long
または unsigned long
の代わりにこれらを使用することができます。
マクロは、定数のサイズと符号を指定するために使用できます。マクロには、INT8_C(c)、 INT16_C(C)、 INT32_C(C)、 INT64_C(c)、 UINT8_C(c)、 UINT16_C(C)、 UINT32_C(C)、 UINT64_C(C) があります。基本的にこれらのマクロは、必要な場合に定数の後に l、ul、ll、または ull を置きます。たとえば、INT64_C(1) は、定数 1 の後に ILP32 の場合には ll を、LP64 の場合には l を付加します。
定数を最大のデータ型にするためのマクロには、 INTMAX_C(c) と UINTMAX_C(c) があります。これらのマクロは、「LP64 への変換のためのガイドライン」で説明している定数の型を指定するのに非常に役に立ちます。
<inttypes.h> に定義されている制限値は、さまざまな整数型の最小値および最大値を指定する定数です。これには、INT8_MIN、 INT16_MIN、 INT32_MIN、 INT64_MIN、 INT8_MAX、 INT16_MAX、 INT32_MAX、 INT64_MAX、およびそれらの符号なしの場合のものなど、各固定幅型の最小値と最大値が指定されています。
最小サイズ型のそれぞれの最小値と最大値も指定されています。これらには、INT_LEAST8_MIN、 INT_LEAST16_MIN、 INT_LEAST32_MIN、 INT_LEAST64_MIN 、INT_LEAST8_MAX、 INT_LEAST16_MAX、 INT_LEAST32_MAX、 INT_LEAST64_MAX、およびそれらの符号なしのものなどがあります。
サポートされている整数型のうちの最大の型の最小値と最大値も定義されています。これらには、INTMAX_MIN と INTMAX_MAX、およびそれらの符号なしのものがあります。
書式指示子 printf(3S) と scanf(3S) を指定するためのマクロも <inttypes.h> にあります。これらのマクロは、引数のビット数がマクロ名に組み込まれている場合に、初期指示子の先頭に l または ll を付加することによって引数を long
または long long
として指定します。
printf(3S) 書式指示子用のマクロは、10 進、8 進、符号なし、16 進の、8 ビット、16 ビット、32 ビット、64 ビットの整数、最小整数型と最大整数型を出力するためのものです。次の例を参照してください。
int64_t i; printf("i =%" PRIx64 "¥n", i);
同様に、scanf(3S) 書式指示子用のマクロが、10 進、8 進、符号なし、および 16 進の 8 ビット、16 ビット、32 ビット、64 ビットの整数、ならびに最小整数型と最大整数型の読み込み用に提供されています。
uint64_t u; scanf("%" SCNu64 "¥n", &u);
これらのマクロは、無制限に使用しないでください。これらは固定幅型と一緒に使用するのが最適な使用方法です。詳細は、「固定幅整数型」を参照してください。
Sun WorkShop Compilers C のバージョン 5.0 に lint(1) プログラムの新しいバージョンが Sun から提供されています。64 ビットで発生する可能性がある問題を検出できるように強化され、コードを 64 ビット安全にするのに役に立ちます。また、C コンパイラの -v コンパイルオプションも便利です。このオプションを使用すると、コンパイル時に通常のチェックに加えて、より厳しい意味解析上のチェックが行われます。さらに、引数として指定したファイルに対して lint に似たチェックも実行します。
コードを 64 ビット安全に修正する場合、64 ビット環境用の派生型とデータ構造を正しく定義しているヘッダーファイルを使用してください。つまり、Solaris 7 オペレーティング環境にあるヘッダーファイルを使用してください。
Sun WorkShop Compilers C のデバッグ機能と lint(1) の詳細については、『C ユーザーズガイド』を参照してください。
lint(1) は、32 ビットコードおよび 64 ビットコードの両方に使用することができます。32 ビット環境および 64 ビット環境の両方で実行するコードには、-errchk=longptr64 オプションを使用します。-errchk=longptr64 フラグは、ロング整数とポインタのサイズが 64 ビットで、かつ普通の整数が 32 ビットである環境への移植性を調べるのに使用します。
-Xarch=v9 オプションは、64 ビット SPARC 環境で実行するコードに対して lint を実行する場合に使用します。64 ビット SPARC 上で実行するコードに対して、発生する可能性がある 64 ビット関連の問題について警告を表示するようにするには、-Xarch=v9 オプションと共に -errchk=longptr64 オプションを使用します。
lint には -D__sparcv9 オプションを使用しないでください。
警告がある場合、 lint(1) は、エラーが発生した行の行番号、問題を説明する警告メッセージ、およびポインタが関わっているかどうかを出力します。関連する型のサイズも示されます。ポインタが関わっているかどうかおよび型のサイズを知ることは、64 ビット問題を特定し、さらに 32 ビットとそれより小さい型との間の問題を避けるのに役に立ちます。
lint は発生する可能性がある 64 ビット関連の問題に関して警告を出すことはできますが、問題をすべて検出できるわけではありません。また lint が出力する警告の中には 64 ビット関連以外の問題が含まれていることもあります。警告が出されていても、そのコードは特定の意図に沿って記述されていてアプリケーションにとって適切なコードである、という場合がよくあります。
次に、考慮すべき警告をいくつか例として示します。
/*LINTED*/ コメントをその前の行に置くと、任意のソース行に対する警告を抑止できます。これは、意図的に特別な動作をコード中に記述したい場合には役に立ちます。例としては、キャストや代入の場合があります。/*LINTED*/ コメントは、実際に問題がある場合にもそれを検出しないようにするので、使用する際は十分に注意してください。lint(1) コマンドについての詳細は、『C ユーザーズガイド』または lint(1) のマニュアルページを参照してください。
lint(1) を使用する際には、すべての問題が lint(1) によって警告として検出されるわけではないこと、変更が不要な点についても lint(1) によって警告として出力されることがある、ということを憶えておいてください。警告の内容は、目的と照らし合わせて調べてください。これから示す例では、コードを変換する際に遭遇する可能性が高い問題を説明します。
int
とポインタは、ILP32 環境では同じサイズであるため、多くのコードがこの仮定に基づいています。ポインタは、アドレス計算の際に int
または unsigned int
にキャストされることがあります。また、ポインタは long
にキャストすることもできます。long
とポインタは、ILP32 および LP64 とで同じサイズだからです。unsigned long
を明示的に使うかわりに、uintptr_t
を使用してください。uintptr_t
は、意図することがより明確にわかり、コードをより移植可能なものにして、その結果将来変更があっても影響されないようにするためです。
char *p; p = (char *) ((int)p & PAGEOFFSET); % warning: conversion of pointer loses bits
推奨される使用法
char *p; p = (char *) ((uintptr_t)p & PAGEOFFSET);
int
と long
は、ILP32 では実際には区別されないため、意図的あるいは非意図的にそれらは交換可能であると仮定して、既存のコードの多くで区別することなく使用されています。このように int
と long
が同じサイズとして仮定しているコードは、ILP32 および LP64 で動作するように変更しなければなりません。ILP32 データ型モデルでは、int
と long
は 32 ビットですが、LP64 データ型モデルでは long
は 64 ビットです。
int waiting; long w_io; long w_swap; ... waiting = w_io + w_swap; % warning: assignment of 64-bit integer to 32-bit integer
符号の拡張は、64 ビットに変換する際によく発生する問題です。符号の拡張について lint(1) は警告を出さないため、実際に問題が発生する前に問題を検出するのは困難です。さらに、型変換および型昇格に関する規則には不明瞭な部分もあります。符号拡張の問題を解決するには、意図する結果を得ることができるように明示的なキャストを使用する必要があります。
ANSI C の変換規則を理解しておくと、なぜ符号の拡張が発生するかを理解するのに役立ちます。32 ビットおよび 64 ビットの整数値間において、符号拡張の問題の原因になることがある変換規則は、次のとおりです。
整数の昇格
char
、short
、列挙型、または ビットフィールド型は、符号付きあるいは符号なしに関わらず、int
を呼び出す式の中で使用できます。int
が元の型の取り得る値をすべて格納することができる場合は、その値は signed int
に変換されます。そうでない場合は、unsigned int
に変換されます。
符号付きおよび符号なし整数間の変換
負の符号付き整数が、サイズが同じまたはより大きい型の符号なし整数に昇格される場合、最初に大きい型の符号付きの値に昇格され、その後符号なしの値に変換されます。
変換規則についての詳細は、ANSI C 規格を参照してください。この規格には、通常の算術変換や整数定数についての規則が規定されています。
64 ビットプログラムとしてコンパイルした場合、次の例の addr
変数は、addr
および a.base
が符号なしの型であっても符号付きの型に拡張されます。
%cat test.c struct foo { unsigned int base:19, rehash:13; }; main(int argc, char *argv[]) { struct foo a; unsigned long addr; a.base = 0x40000; addr = a.base << 13; /* 符号拡張あり */ printf("addr 0x%lx¥n", addr); addr = (unsigned int)(a.base << 13); /* 符号拡張なし */ printf("addr 0x%lx¥n", addr); }
このように符号拡張が発生するのは、変換規則が次のように適用されるからです。
a.base が、整数の昇格規則によって、unsigned int
から int
に変換されます。このため、式 a.base << 13 は int
型ですが、符号拡張はまだ発生していません。
式 a.base << 13 は、int
型ですが、符号付きおよび符号なしの整数昇格規則によって最初に long
へ変換され、その後 unsigned long
へ変換された後、 addr
に代入されます。符号拡張は、この式が int
から long
に変換されるときに発生します。
% cc -o test64 -xarch=v9 test.c % ./test64 addr 0xffffffff80000000 addr 0x80000000 % |
同じ例題が 32 ビットプログラムとしてコンパイルされた場合、符号拡張は発生しません。
% cc -o test32 test.c % ./test32 addr 0x80000000 addr 0x80000000 % |
一般に、ポインタ演算を使用した場合の方が、アドレス演算を使用した場合よりもうまく機能します。この理由は、ポインタ演算はデータ型モデルに依存しませんが、アドレス演算はデータ型モデルに依存するためです。さらにポインタ演算の方がコードを簡潔に記述することができます。
int *end; int *p; p = malloc(4 * NUM_ELEMENTS); end = (int *)((unsigned int)p + 4 * NUM_ELEMENTS); % warning: conversion of pointer loses bits
推奨される使用法
int *end; int *p; p = malloc(sizeof (*p) * NUM_ELEMENTS); end = p + NUM_ELEMENTS;
パディングが必要な場所について、アプリケーションにおける内部データ構造をチェックする必要があります。LP64 データ型モデルでは long
またはポインタフィールドは 64 ビットに拡張されるので、境界を整列するために構造体内のフィールド間にパディングを行うことができます。SPARC プラットフォーム上の 64 ビット環境では、構造体の型はすべて、少なくとも構造体内にある一番大きいサイズに整列されます。構造体を再構成するための簡単な規則は、long
とポインタのフィールドを構造体の始めの位置に移動することです。
struct bar { int i; long j; int k; char *p; }; /* sizeof (struct bar) = 32 */
推奨される使用法
struct bar { char *p; long j; int i; int k; }; /* sizeof (struct bar) = 24 */
共用体フィールドは、ILP32 と LP64 とでサイズが変更されているので、必ず確認してください。
typedef union { double _d; long _l[2]; } llx_t;
推奨される使用法
typedef union { double _d; int _l[2]; } llx_t;
一部の定数式では、精度が不足するためにデータが失われる可能性があります。このような問題を検出するのは非常に困難です。各整数定数の後に (u、U、l、L) を組合せたものを追加して、定数式にデータ型を明示的に指定してください。キャストを使用して定数式のデータ型を指定することもできます。
int i = 32; long j = 1 << i; /* 右辺は整数式なので、j には 0 が */ /* 代入されます */
推奨される使用法
int i = 32; long j = 1L << i;
Sun WorkShopTM で提供される C コンパイラは、モジュールに使用されかつ extern
として定義または宣言されていない関数または変数に対してそのデータ型を int
とみなします。このように使用される long
およびポインタは、コンパイラの暗黙的な int
宣言によって切り捨てられます。関数または変数に対する適切な extern
宣言は、C モジュール中にではなくヘッダーに置いてください。このヘッダーは、関数または変数を使用する C モジュールがインクルードするようにしてください。これがシステムヘッダーに定義されている関数または変数であっても、適当なヘッダーをコード内にインクルードしてください。
int main(int argc, char *argv[]) { char *name = getlogin() printf("login = %s¥n", name); return (0); } % warning: improper pointer/integer combination: op "=" warning: cast to pointer from 32-bit integer implicitly declared to return int getlogin printf
推奨される使用法
#include <unistd.h> #include <stdio.h> int main(int argc, char *argv[]) { char *name = getlogin(); (void) printf("login = %s¥n", name); return (0); }
LP64 データ型モデルでは、sizeof() は unsigned long
の実効的なデータ型をもちます。sizeof() は、int
型 の引数を期待する (受け取る) 関数に渡されたり、int
に代入またはキャストされることがあります。このような切り捨てによってデータが失われることがあります。
long a[50]; unsigned char size = sizeof (a); % warning: 64-bit constant truncated to 8 bits by assignment warning: initializer does not fit or is out of range: 0x190
関係式には変換規則があるので、注意を要します。必要に応じてキャストを追加して、式をどのように評価するかを明示的に記述してください。
printf(3S)、 sprintf(3S)、 scanf(3S)、 sscanf(3S) が long
またはポインタ引数に対して使用されている場合、それらを long
またはポインタ引数用に変更する必要がある場合があります。ポインタ引数を 32 ビットおよび 64 ビット環境で動作させるためには、書式文字列に指定する変換操作を %p にしてください。
char *buf; struct dev_info *devi; ... (void) sprintf(buf, "di%x", (void *)devi); % warning: function argument (number) type inconsistent with format sprintf (arg 3) void *: (format) int
推奨される使用法
char *buf; struct dev_info *devi; ... (void) sprintf(buf, `di%p", (void *)devi);
long
引数の場合は、long
サイズ指定子 l を書式化文字列の変換操作文字の前に追加してください。さらに、buf
によって示される記憶領域に 16 桁を格納できる大きさが十分にあることを確認してください。
size_t nbytes; u_long 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); % 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
推奨される使用法
size_t nbytes; u_long align, addr, raddr, alloc; printf("kalloca:%lu%%%lu from heap got%lx.%lx returns%lx¥n", nbytes, align, raddr, raddr + alloc, addr);
アプリケーションを完全に 64 ビットプログラムに変換する際によく発生する、その他の問題を取り上げます。
64 ビットアプリケーション環境で 64 ビットを表わすために、多くの派生型が変更されました。この変更は、32 ビットアプリケーションには影響を与えませんが、これらの型で記述されるデータを使用またはエクスポートする 64 ビットアプリケーションは、再評価して正しく動作することを確認する必要があります。たとえば、utmp(4) または utmpx(4) ファイルを直接操作するアプリケーションについては再確認が必要です。64 ビットアプリケーション環境で正しく動作するように、これらのファイルへ直接アクセスしないようにしてください。代わりに getutxent(3C) および関連する関数を使用してください。
付録 A 「派生型の変更」 には、変更された派生型の一覧が記載されています。
ある部分で型の変更を行なった結果、別の部分で予期しない 64 ビット変換が起きることがあります。たとえば、以前には int
を戻していたが現在は ssize_t
を返す関数に対しては、すべての呼び出し側をチェックする必要があります。
long
は ILP32 データ型モデルでは 32 ビット、LP64 データ型モデルでは 64 ビットなので、以前は long
として定義されたものが不適切または不要になることがあります。このような場合は、より移植性の高い派生型を使うこともできます。
上述の理由で、LP64 データ型モデルにおいて多くの派生型が変更されている場合があります。たとえば、pid_t
は 32 ビット環境では long
のままですが、64 ビット環境では int
です。LP64 コンパイル環境用に修正された派生型のリストについては、付録 A 「派生型の変更」 を参照してください。
32 ビットおよび 64 ビット用にそれぞれ固有のインタフェースが必要な場合があります。ヘッダーで _LP64 または _ILP32 という機能テストマクロを使用することによって、それぞれのインタフェースを設けることができます。同様に、32 ビットおよび 64 ビット環境で動作させるコードに、それぞれのコンパイル環境に応じて適切な #ifdef を使用する必要がある場合もあります。
構造体を値渡しで渡し、SPARC V9 用のコードをコンパイルする場合、構造体が小さいと、その値のコピーを指すポインタとしてではなくレジスタ経由で値が渡されます。これは、C コードと手作業で記述したアセンブリコードとの間で構造体を渡す際に問題が発生します。
浮動小数点パラメータも同様に動作します。つまり、値渡しで渡された浮動小数点の値が、浮動小数点レジスタに渡される場合があります。
コードを 64 ビット安全にした後、コードを再検討して、アルゴリズムおよびデータ構造が意図どおりであることを確認してください。データ型が大きいほど、データ構造体はより大きい空間を使用します。コードのパフォーマンスも同様に変化する場合があります。これらのことを考えて、コードを適切に修正する必要があるかもしれません。
以下の各項目を確認していくことによって、コードを 64 ビットに変換する必要があるかどうかを判断することができます。
このマニュアル全体をお読みください。特に 「LP64 への変換のためのガイドライン」に重点を置いて読んでください。
すべてのデータ構造体とインタフェースを再検討して、それらが 64 ビット環境でも有効であることを確認してください。
<sys/types.h> (または、少なくとも <sys/isa_defs.h>) をコードにインクルードして、_ILP32 または _LP64 の定義やその他の基本派生型を組み込んでください。
関数プロトタイプおよび非局所的な有効範囲を持つ外部宣言をヘッダーに移動し、それらのヘッダーをコードにインクルードしてください。
-errchk=longptr64 および -Xarch=v9 フラグを指定して lint(1) を実行し、各警告メッセージを確認してください (すべての警告どおりに変更が必要なわけではありません)。結果として必要になる変更によっては、32 ビットおよび 64 ビットモードで lint(1) を再実行する必要があります。
アプリケーションを 64 ビット専用としてだけで提供する予定でない場合は、コードを 32 ビットおよび 64 ビットとしてコンパイルしてください。
32 ビットオペレーティングシステム上で 32 ビットバージョンのアプリケーションを実行し、そのアプリケーションをテストしてください。64 ビットオペレーティングシステム上で 32 ビットバージョンのテストも実行できますが、その必要はありません。