ishikawa
ishik****@yk*****
2013年 8月 26日 (月) 19:17:57 JST
On (2013年08月25日 00:02), ISHIKAWA,Chiaki wrote: > (2013/08/24 19:07), 1xx wrote: >> すみません、途中で送信してしまいました。 >> >> 2013年8月24日 19:03 1xx <itsan****@gmail*****>: >>> 2013年8月24日 15:54 1xx <itsan****@gmail*****>: >>>> 2013年8月24日 14:33 1xx <itsan****@gmail*****>: >>>>> 2013年8月21日 1:49 ISHIKAWA,chiaki <ishik****@yk*****>: >>>>> >>>>> 問題の有りそうなところを切り出してsourceを小さくしていきました。 >>>>> 添付fileの様なcrypt(3)とprintf(3)だけを使う小さなprogramを書きました。 >>>>> これでもvfprintf.cの中でSEGVで落ちます。 >>>>> Debian 7.1 x64, openSUSE 13.1 Milestone 4 x64 の環境で落ちます。 >>>>> Debian 7.1 x86 だとSEGVにならず、encryptされた文字列を出力します。 >>>>> なにやら64 bit版の-lcrypt libraryが怪しいような気がしてきました。 >>>>> もう少し調べて、openSUSEの方にbug reportを出そうと思います。 >>>> >>>> openSUSEの方にbugreportを書きました。 >>>> https://bugzilla.novell.com/show_bug.cgi?id=836541 >>>> >>>> Debianの方にも後でbugreportを書いておきます。 >>> >>> すみません、この件ですが、programに機能検査マクロ >>> #define _XOPEN_SOURCE >>> を定義するだけで正常に暗号化された文字列を出力するようになりました。 >> >> 結果的に添付fileの様なprogramになりました。 >> >> bugreportは自分でcloseしておきます。 >> >> atodのsourceを見直して、同じ問題でないか調べてみます。 >> > > 石川です。 > > configure で必要な環境では、_XOPEN_SOURCEを定義するように > しないといけないかもしれませんね。 > > atod.cのincludeがおかしい点も、 > _XOPEN_SOURCEを定義すれば問題なくなり、CPPのマクロのチェックの > 結果、無事にcrypt.h, time.hがincludeされるのかもしれません。 > 明日以降チェックしてみます。 > env CC="c-compiler-program -D_XOPEN_SOURCE=550" ./configure のようにして、コンパイルしてみたところ、（gcc-4.8 をコンパイラとして利用 し、 make CCOPTIONS="-Werror -Wall" でコンパイル。） いくつか（多分これまでコンパイルされていなかった部分で？） 問題がみつかりま した。 - unsigned のスペルミス。 - マクロの値の連鎖の結果、配列の大きさの計算で使われいる マクロ WNN_NFD はコンパイル時のコンスタントとなる必要があるのに、 getdtablesize() として定義される。 工夫して、WNN_NFD には適当な値を 定義し、それが問題ないか実行時にgetdtablesize() の値と比較 チェックするようにしました。 - wnn_fd_mask, wnn_fd_set のタイプ宣言の間違い。 おもに wnn_os.h の中の変更です。 その他 bzero(), bcopy(), bcmp(), rindex() が <strings.h> で定義されているの に、<strings.h> が正しくinclude されない問題を発見、修正： たとえば etc/bdic.c ですと次のような問題がありました： 下にcpp でのinclude 部分を示しますが 要は、STDC_HEADERSが定義されている、いないに関わらず strings.h があれば存在 すれば 問答無用でstrings.h をinclude すべきです。いくつか同じような問題をかかえた ファイルを修正しました。（コンパイル時に警告がでないファイルは修正しきれてい ません。INET6 などが定義されているとbcopy が使われるファイルなどは未修正のも のもあるかもしれません。） /* bcopy is used without declaration when configured with -D_XOPEN_SOURCE=650 under Debian GNU/Linux 32bits. */ /* The sequence below is a suspect: #if STDC_HEADERS # include <string.h> #elif HAVE_STRINGS_H # include <strings.h> #endif STDC_HEADERS */ #if STDC_HEADERS # include <string.h> #endif /* STDC_HEADERS */ #if HAVE_STRINGS_H # include <strings.h> #endif すこし前にのべた -Werror -Wall で片っ端から警告をなくすための すこしコードの構成を変更したものに以上の追加をしました。 （ただし別の投稿で指摘のあった、char*, short int * などの関数引数の混合の問 題は (void*) でキャストすることで 誤魔化してます。） それ以外の変更は、結構重要な変更かとおもいます。 (sockname をheader で決めうちしているのは10年以上前に、なにかの目的で変更し ようとして、きれいでないとおもって、ローカルに変更したことを思い出しました。 今回、とりあえずヘッダー中ですが、関数を用意してその中で設定するようにしたの で、transport や protocol に応じて変更するのが＊多少＊楽になるかもしれませ ん。（というのは大げさで、変更しようとしたらそれにともなう 変更を多数おこなう必要があります。すくなくとも、関数になっていることで 多少とっつき易くなりました。） 変更したソースはとりあえず 32bits の上では -D_XOPEN_SOURCE=550 を設定して configure した場合の jserver も動作しています -D_XOPEN_SOURCE=550 を設定しないでconfigure したものは 32bits, 64bits の両方 で動作することを確認しました。 ただし、client プログラム (atod など）はmake の最中の動作くらいしかテストさ れてません。 ソースの変更は細かなパッチ形式になっておらず、しかもdebian用にファイルのレ イアウトなどを指定したものですが、*.[ch] の変更は参考になるかとおもいますの で、どこかに公開する予定です。 なお、gcc-4.8 の警告のひとつは if, while, for などの 条件式のところに "=" が使われていると、代入文の周りに括弧をつけろというもの です。 例 (a) if (a = b && c = d) のような場合には、これが a = (b && c = d) なのか (a = b) && (c = d) なのかを示すことは可読性をあげる場合には重要です。 実例（b） 実際2箇所（１箇所だったか）で a = functioncall == -1 みたいなところがあり、正直 オリジナルの意図が (a = functioncall) == -1 なのか a = (functioncall == -1) なのか判断に迷うところがありました。 もちろん C 言語的には一方になるのですが、 どうも元のコードを書いた人の意図と異なっているようで、 どちらを意図していたのか 非常に怪しいところです。 ですが、gcc-4.8 の警告の不便なところは、if (a = b )のように、"=" 一つしかな く、他に&& とか || がないにも括弧をつけろと警告されてしまいます。（上の実例 （b） は ==がある事例） テスト目的で -Wall -Werror をつけていたために、コンパイルが先にすすめず, こ れを if ((a = b) ) のように修正してしまいましたが、あまりうれしくない変更です。 石川 PS: _XOPEN_SOURCE=550 は最初 650で定義しておこなったのですが、 いくつかの関数が 600 以上では宣言、定義されないということがわかったので 550に落したものです。数箇所かそれでもうまく宣言、定義されず 無理矢理 __USE_BSD を局所的に 定義して宣言を取り込んでいるところがあります が、_XOPEN_SOURCE は crypt() の利用に問題があったために定義したもので、他に は大きな問題を与えてないはずです。 （とりあえず jserver は動作してますし。）
Fork