64bit対応

Question

32bitマシンで使っていたソースを、64bit化する際に
気をつけたこと、困った経験などがありましたら、教えて下さい。

どういったことが問題になるのか、勘所がわからないので、
勉強の為に質問させていただきました。
具体例なんかあると嬉しいです。
よろしくお願いします。

tatsu99 · Accepted Answer

#3です。
＞tatsu99さんは、64bit対応の際に、まずそれぞれの型のバイト長を
＞調べて、2.long型を使用しないとされたんでしょうか。
その通りです。プログラマたるもの、そのぐらいは常識です。
マニュアルで調べ、かつ全ての型を、
printf("charのサイズ=%d",sizeof(char));
printf("char*のサイズ=%d",sizeof(char*));
printf("intのサイズ=%d",sizeof(int));
のようにして調べて下さい。
その結果、long型が３２ビットと６４ビットで異なるため通常は使用しないようにしました。

＞私はintを使わないようにと言われたことがあります。
＞なぜなのかよくわかってないので、
int型は、かつての古きよき時代（MS-DOSの時代）には２バイトでした。そのため、int型は、ＯＳによりサイズが異なると思っている人が多いです。そのために、上記のことをいわれたのかと思います。この認識は、正しい場合もあり、そうでない場合もあります。（HP-UX,solarisでは正しくありません）
どのＯＳ（又はコンパイラ）で、６４ビットにするかは、わかりませんが、それが、明確になったとき、全ての型のサイズを自分で調べることが、大切です。

Tacosan · Answer

まあ, 重要なのは「この型なら大きさはこれだけ」という仮定をおかないってことでしょうか. もっとも, 規格を作る方も「全然仮定できないとどうにもならない」ってことは理解したらしく, 今の ANSI C では「そこそこの仮定」を許すためのヘッダとして stdint.h が用意されています.
ちなみに 64ビット化に関しては LP64, ILP64, LLP64 なんて表現があって
LP64: int = 32ビット, long = 64ビット
ILP64: int = long = 64ビット
LLP64: int = long = 32ビット, long long = 64ビット
だったような気がします. なので, 厳密には「long を使わなければ安全」でもない. もっというと sizeof(long long) = 1 かもしれないんですが, まあそんな環境は現れないと思いたい (苦笑).
で, #2 で言ってるのは「sizeof(int) = 4 を仮定するコード」(つまり sizeof(int) を使わずリテラルの 4 をそのまま使うコード) はしばしばあったりするんだけど同様に「sizeof(void*) = 4 を仮定する」あるいは「sizeof(void*) = sizeof(int) を仮定する」コードもある, って話. 今どきのコードではどうか知りませんが, ちょっと古いコードだと結果的にこのような仮定ができてしまって「コンパイルできね～」とか悩むことになったりします, というか実際悩みました.

tatsu99 · Answer

HPとsolarisで６４ビット化を行った時の経験です。
int型は４バイトのままです。long型が３２ビットと６４ビットで異なります。
また、ポインターのsizeが異なります。
まとめると、以下のようになります。
　　　　　　　３２ビット　　６４ビット
char　　 　　　１バイト　　　１バイト
short　　　　　２バイト　　　２バイト
int　　　　　　４バイト　　　４バイト
long   　　　 ４バイト　　　８バイト
long long int ８バイト　　　８バイト
ポインター　　　４バイト　　　８バイト
３２ビットへの移植を考慮した場合、以下の点がポイントになります。
１．ポインターのサイズを４バイトと決めつけない
２．long型を使用しない
３．８バイト整数は、longではなくlong long intを使う
４．ＯＳから提供されるシステムコールのパラメータについては、
その型をそのまま使う。
size_t,time_t,pid_t等（これらは、最終的にはlong型にたどり着く可能性がありますので、int型で代用すると、痛い目に合います。）
size_t,time_t等は、３２ビットか６４ビットかにより、サイズが異なる可能性があります。（実際、solarisでは異なっていました）
従って、本来time_tを使うべきところで、intを使っていると６４ビット化したとき、バグを誘発する可能性があります。

LINUX,windowsでの６４ビット化は、やったことがないので、上記が当てはまるかどうかは、不明です。
上記の前提が、あてはまるとすれば、
３２ビットのソースで、下記の点が、あるかどうかをチェックした方が良いでしょう。 
１．ポインターを４バイトに決めつけているソースがないか。
２．time()の戻り値はtime_t型で受けるべきであるが、intで受けてないか等。一般的には、システムコールの本来の型で受けるべきものを、intで受けてないか。

Tacosan · Answer

sizeof(void*) = sizeof(int) = 4 を仮定してるコードが意外とあるので注意.

maimi09 · Answer

Ｉ/Ｏを叩いているなどメモリのリソース管理をしている場合は今までなかった上位３２ビットを０で埋めておかないと、３２ビットアプリを６４ビットＯＳで動かすと管理しきれなくなるというのが考えられます。

通常のアプリケーションをＣライブラリを用いて６４ビット用オプション付きで再コンパイルする分には（コンパイラの文法が改訂になった場合を除いて）あまり気にする部分は無いと思われます。

intの長さが３２ビットから６４ビットに変更になっている場合はキャストやシフト演算の互換性に注意がいるとおもわれます。

64bit対応

#3です。

HPとsolarisで６４ビット化を行った時の経験です。

sizeof(void*) = sizeof(int) = 4 を仮定してるコードが意外とあるので注意.

この回答への補足

Ｉ/Ｏを叩いているなどメモリのリソース管理をしている場合は今までなかった上位３２ビットを０で埋めておかないと、３２ビットアプリを６４ビットＯＳで動かすと管理しきれなくなるというのが考えられます。

似たような質問が見つかりました

このQ&Aを見た人はこんなQ&Aも見ています

関連するカテゴリからQ&Aを探す

このQ&Aを見た人がよく見るQ&A

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング