２００２年５月 １２日日曜日

pm 23:05

そんで、どうもnxtは悪くないようだ。
っていうか、前にも妙な動作をしたことがあったのだ。
そんで、ソースを分割して、infnxtなどを作ったんだよ。
だから、「そういう仕様」ってことにしておこう。うむ。

だもんで、やたらデカイtar ballになっているが、nxt 2.3.1でいいや。
今後が面倒ではあるが。
まさか、長いソースになると、誤動作を起こすなんて・・・

いや、そもそも、nxtがヘボなプログラムだってのがあるが。
そんなことは考えられないが、どうもそういうことのような気がする。
でも、nxt.cよりも長いソースなんてザラだから、やっぱ、nxt.cのなんかのバグだろう。
他のLinuxで試すのもいいが、その実験のためにインストールするのが面倒だ。
パーティション的には、Free BSDのところがあるのだが、消したくない。
設定が面倒で、あんまりいじっていないんだけど。

だから、結論としては、「nxt 2.3.1のtar ballパッケージで行く」である。
原因については、「nxtのプログラミングの設計がよくないので、コンパイルすると、文字化けを起こす」 ということにする。
だから、「ソースを短く分割して、それぞれにわけた、nxt 2.3.1は安定している」だ。
でも、ソースが長くなったり、条件コンパイルで誤動作を起こすなんて、考えられない。
だが、同じソースをFree BSDでコンパイルすると、まったく問題が発生しない。

しかし、nxtよりも長いソースのプログラムは山のようにある。
もちろん、複雑な#ifdefの嵐のプログラムも。

一体、なんだろう？
もしかすると、初期化していないポインタだとか？
初期nxtをinfnxtやnxtgetなどに分割したときのデータは残っていないし・・・
そんなことってあるのだろうか？
無いよな・・・
やっぱ、なんらかのnxtのバグだろう。
でも、Free BSDでは安定して動作する。
うーむ・・・

気にしないでおくことにした。