たとえば、Cプログラムを移動するときに直面する可能性のある問題を知りたいです。Tru64 Unix から Linux 64 ビットへのサーバー プロセスとその理由は? どちらも 64 ビット プラットフォームであるため、プログラムに必要となる、または新しい環境でソース コードを再コンパイルするだけで、どのような変更が必要になる可能性がありますか? 少し混乱しています。作業を開始する前に知っておく必要があります。
3 に答える
私は 90 年代初頭 ( OMG は古いと感じます... ) に 32 ビット コードをAlpha アーキテクチャに移植することに多くの時間を費やしました。これは、OSF/1 と呼ばれていた頃のことです。
Alpha から x86_64 に移行する場合、ビット幅に関連する問題はほとんどありません。
sizeof(int) == sizeof(void *)
開発者は、たとえば、それを仮定することによって引き起こされる問題をはるかに認識しています。これは、コードを Alpha に移植するときに私が抱えていた最も一般的な問題でした。
相違点は、POSIX、XOpen などのさまざまな API 仕様への準拠において 2 つのシステムがどのように異なるかという点にあります。
Alpha コードが SVR4 スタイルの API (ストリームなど) を使用している場合、より BSD に似た API を使用している場合よりも困難になる可能性があります。
64 ビット アーキテクチャは、アーキテクチャの分類の近似値にすぎません。
size_t
理想的には、コードは、変数のすべての記述、特にサイズとptrdiff_t
ポインター演算、および[u]intXX_t
特定の幅が想定される型については、「セマンティック」型のみを使用します。
そうでない場合、主なポイントは、すべての標準算術型 (すべての整数型、浮動小数点型、およびポインター) が両方のプラットフォームで同じ概念にマップされているかどうかを比較することです。違いが見つかれば、潜在的な問題点がわかります。
両方のプラットフォームで使用される64 ビット データ モデルを確認してください。ほとんどの 64 ビット Unix ライクな OS は LP64 を使用するため、ターゲット プラットフォームが同じデータ モデルを使用する可能性があります。これは、コード自体がコンパイルおよびリンクされることを考えると、問題はほとんどないはずです。
両方のプラットフォームで同じコンパイラ (GCC など) を使用する場合、互換性のないコンパイラ拡張機能や、未定義または実装定義の動作の違いについて心配する必要もありません。このような動作は、ターゲット アーキテクチャ間で異なる可能性があるため、コンパイラが同じであっても、どのような場合でも回避する必要があります。同じコンパイラを使用していない場合は、拡張機能の使用に注意する必要があります。#pragma ディレクティブは、コンパイラが認識しない #pragma を静かに無視できるため、特定の問題です。
最後に、コンパイルとリンクを行うには、C 標準ライブラリ以外のライブラリの依存関係が両方のプラットフォームで利用可能である必要があります。Unix と Linux は同じ POSIX API を共有しているため、ほとんどの OS 呼び出しが利用可能です。