えー、先日PAEにするかamd64にするか迷っていたFreeBSD機ですが、愛用のjvimをports collectionからインストールしようとして罠にはまりました。
jvim3-canna+freewnnをportinstallしたのは正常にできたわけです。
jvimの起動も一見正常。
でも、かな漢字変換しようとするとcore dump。。。
でmake時のメッセージにpointerをサイズの違う整数型に入れているとか何とか言う趣旨の警告メッセージを発見。
で、こういうプログラムを作って試しました。
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>main ()
{
printf("%d\n", sizeof (char));
printf("%d\n", sizeof (int));
printf("%d\n", sizeof (long));
printf("%d\n", sizeof (long long));
printf("%d\n", sizeof (char *));
printf("%d\n", sizeof (int *));
printf("%d\n", sizeof (long *));
printf("%d\n", sizeof (long long *));
}
さて、これをi386機でコンパイル実行すると、、、
1
4
4
8
4
4
4
4
のようになることは自明と言っても良いでしょう。が、amd64機だと、、、
1
4
8
8
8
8
8
8
となんとまぁ、64ビットだから当たり前と言えば当たり前ですが、ポインタは8バイトになります。どうやら件のプログラム中にはこれをintに入れているのがあると見た。
もっと驚いたのがlongも64ビットになっていることかな。VAX-11以来32ビット機主流が長く続いたから、long=int=32ビットと言う前提のプログラムも多いと言う気もするんだが、、。
逆に考えれば、ポインタをlongに入れていれば問題はなかった、、、ってそういう使い方をさせてしまうC言語の「アセンブラ｣としての側面がそもそもの原因ですね。
もちろん、本来はそれを活用できるのがC言語のうまみであって、アーキテクチャが変われば、それにあわせて変えなきゃならんということを忘れなければいいだけですが、（え？普通のアセンブラとの違い？、ニーモニックが変わらないって事だけでしょう:-)、、。
巷では「高級言語」ってことにされているから、つい忘れてしまうわけですね。
まぁ高級言語でもアーキテクチャ依存性があるものもあるから、Cだけが悪いってわけじゃないですが。
そもそも、charのビット数からして処理系依存なんだってことをなぜ忘れるかって言うと、それだけ世のアーキテクチャが変わり映えしない単調なものになっていたってことで、、、。
PS. 結局jvimはjvim3-direct_cannaなら問題なく使えることがわかったので、それを使おうかと、、。うーん、Wnnにしたかったんだけど。。それに、まだ例の警告が数ヶ所出てるのが怖い。。
