7.4 そのほかの注意事項

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

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

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

7.4.2 変更の副作用の検査

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

7.4.3 long のリテラル使用の合理性の確認

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

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

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

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

7.4.5 呼び出し規則の変更

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

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

7.4.6 アルゴリズムの変更

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