アプリケーションを完全に 64 ビットプログラムに変換する際によく発生する、その他の問題を取り上げます。
64 ビットアプリケーション環境で 64 ビットを表すために、多くの派生型が変更されました。この変更は、32 ビットアプリケーションには影響を与えませんが、これらの型で記述されるデータを使用またはエクスポートする 64 ビットアプリケーションは、再評価して正しく動作することを確認する必要があります。たとえば、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 ビット安全にした後、コードを再検討して、アルゴリズムおよびデータ構造が意図どおりであることを確認してください。データ型が大きいほど、データ構造体はより大きい空間を使用します。コードのパフォーマンスも同様に変化する場合があります。これらのことを考えて、コードを適切に修正する必要があるかもしれません。