その他の考慮事項

アプリケーションを完全に 64 ビットプログラムに変換する際によく発生する、その他の問題を取り上げます。

サイズが拡大した派生型

64 ビットアプリケーション環境で 64 ビットを表すために、多くの派生型が変更されました。この変更は、32 ビットアプリケーションには影響を与えませんが、これらの型で記述されるデータを使用またはエクスポートする 64 ビットアプリケーションは、再評価して正しく動作することを確認する必要があります。たとえば、utmpx(4) ファイルを直接操作するアプリケーションについては再確認が必要です。64 ビットアプリケーション環境で正しく動作するように、これらのファイルへ直接アクセスしないようにしてください。代わりに getutxent(3C) および関連する関数を使用してください。

付録 A 「派生型の変更」 には、変更された派生型の一覧が記載されています。

変更による副作用をチェックする

ある部分で型の変更を行なった結果、別の部分で予期しない 64 ビット変換が起きることがあります。たとえば、以前には int を戻していたが現在は ssize_t を返す関数に対しては、すべての呼び出し側をチェックする必要があります。

long を使用する意味があるかどうかチェックする

long は ILP32 データ型モデルでは 32 ビット、LP64 データ型モデルでは 64 ビットなので、以前は long として定義されたものが不適切または不要になることがあります。このような場合は、より移植性の高い派生型を使うこともできます。

上述の理由で、LP64 データ型モデルにおいて多くの派生型が変更されている場合があります。たとえば、pid_t は 32 ビット環境では long のままですが、64 ビット環境では int です。LP64 コンパイル環境用に修正された派生型のリストについては、付録 A 「派生型の変更」 を参照してください。

明示的な 32 ビット対 64 ビットプロトタイプのために #ifdef を使う

32 ビットおよび 64 ビット用にそれぞれ固有のインタフェースが必要な場合があります。ヘッダーで _LP64 または _ILP32 という機能テストマクロを使用することによって、それぞれのインタフェースを設けることができます。同様に、32 ビットおよび 64 ビット環境で動作させるコードに、それぞれのコンパイル環境に応じて適切な #ifdef を使用する必要がある場合もあります。

呼び出し規約の変更

構造体を SPARC V9 用の値渡しで渡す場合、構造体が小さいと、その値のコピーを指すポインタとしてではなくレジスタ経由で値が渡されます。これは、C コードと手作業で記述したアセンブリコードとの間で構造体を渡す際に問題が発生します。

浮動小数点パラメータも同様に動作します。つまり、値渡しで渡された浮動小数点の引数が、浮動小数点レジスタに渡される場合があります。

アルゴリズムの変更

コードを 64 ビット安全にした後、コードを再検討して、アルゴリズムおよびデータ構造が意図どおりであることを確認してください。データ型が大きいほど、データ構造体はより大きい空間を使用します。コードのパフォーマンスも同様に変化する場合があります。これらのことを考えて、コードを適切に修正する必要があるかもしれません。