7.4 変換に関するその他の注意事項

この節では、アプリケーションを完全な 64 ビットプログラムに変換するときに発生する問題を取り上げます。

7.4.1 注: サイズが大きくなった派生型

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

7.4.2 変更の副作用の検査

ある場所で型を変更したために、別のコード部分で予想外の 64 ビット変換が発生することがあります。たとえば、それまで int を返していて、現在は ssize_t を返す ようになった関数のすべての呼び出し元を検査してください。

7.4.3 long のリテラル使用の効果持続の確認

long と定義された変数は、ILP32 データ型モデルでは 32 ビット、LP64 データ型モデルでは 64 ビットです。可能な場合は、変数を定義し直し、移植性に優れた派生型を使用することによって問題を回避してください。

この問題に関連して、LP64 データ型モデルでは、いくつかの派生型が変更されています。たとえば、pid_t は 32 ビット環境では long のままですが、64 ビット環境では pid_t は int です。

7.4.4 明示的な 32 ビットと 64 ビットプロトタイプに対する #ifdef の使用

場合によっては、32 ビットや 64 ビット専用のインタフェースを使用しなければならないことがあります。これらのバージョンは、ヘッダー中で _LP64 または _ILP32 機能テストマクロを指定することによって区別できます。同様に、32 ビットまた 64 ビット環境で動作するコードでは、コンパイルモードに従って適切な #ifdefs を使用する必要があります。

7.4.5 呼び出し規則の変更

構造体を値によって渡し、64 ビット環境用にコードをコンパイルした場合、その構造体は、コピーへのポインタとしてではなく、レジスタ中で渡されます (構造体がそのようにできるほどの大きさの場合)。C コードと手書きのアセンブリコード間で構造体を渡そうとすると、この処理によって問題が起きる可能性があります。

浮動小数点パラメータも同様に機能します。値で渡される一部の浮動小数点値は浮動小数点レジスタ中で渡されます。

7.4.6 アルゴリズムの変更

64 ビット環境で安全なコードを作成したら、コードを見直して、アルゴリズムとデータ構造体が正しく機能することを確認してください。データ構造体のデータ型が大きいほど、使用する空間が増えることがあります。コードのパフォーマンスも影響を受けるかもしれません。こうしたことに注意し、必要に応じてコードを修正してください。