Mitsutoshi NAKANO
itsan****@gmail*****
2015年 6月 21日 (日) 10:44:01 JST
2015年6月21日 1:31 Tomoki AONO <aono****@cc*****>: > 青野です。毎度毎度レスポンスが遅くてすみません。 > ＃FreeWnn特有の話なので、debian-develは外しています。 > > <CANW2+itarEJCUAN-X4OPJpxhhAVmNg6_3Z2UU****@mail*****>の記事において > itsan****@gmail*****さんは書きました。 > >> そこで気づいたのですが、今の build system は昔よりも >> printf() 系 functions の error check が厳しくなったようです。 >> >> printf(STRING) だけだと compile error が >> 出るようになっています。 >> >> (f)printf() に関しては printf("%s", STRING) となるように patch >> を書きました。 >> >> しかし、今度は print_msg_getc() という FreeWnn の function で >> error を指摘され、 patch の必要があります。 > (略) >> print_msg_getc() も printf() と同じく format を argument に取る >> function です。 >> source では 4 つの arguments を取る function として >> 定義されています。 >> >> In Xwnmo/xwnmo/printf.c: >> void >> print_msg_getc (format, arg1, arg2, arg3) >> register char *format; >> char *arg1, *arg2, *arg3; > > 違います。Xwnmo/ 下のソースは使われていません(xwnmoも使える > ようになるといいですけど…)。uumでは、Wnn/uum/sdefine.h で > 定義されているマクロが利用されます。 実は昨日作業していて、勘違いに気付きました。 青野さんが仰る通り Wnn/uum/*.c の print_msg_getc() は Wnn/uum/sdefine.h で定義されている macro でした。 > > In Wnn/uum/sdefine.h: > > #define print_msg(X) {push_cursor();throw_c(0); clr_line();printf(X);flush();pop_cursor();} > #define print_msg_getc(X) {push_cursor();throw_c(0); clr_line();printf(X);flush();keyin();pop_cursor();} > > ＃以前はさらに数行上のprintfマクロでの効果で独自実装の > ＃printf()を使っていたかな? (Wnn/uum/sheader.h 、 > ＃Wnn/uum/printf.c) > > 試してはいませんが、パラメータを括弧でまとめて > 「print_msg_getc(("%s", MSG_GET(nn)));」 > くらいでしのげるかもしれません。そもそも引数が一つだけであ > ればマクロ定義部で呼んでいるprintf()をfputs()などで置き換え > ることも可能そうです。 printf() を fputs() で置き換える方向で動こうと思います。 > >> ついでに今回修正する function だけでも K&R -> ANSI に style >> を変えようと思います。 >> >> これらの変更がまずいという方はいらっしゃいますか? > > format string vulnerabilityの可能性(あるのだろうか)をつぶす > ことや関数宣言部のスタイル変更については問題ないのではない > でしょうか。 幸いにして私が修正した範囲では printf(string) となっている個所の string に % 等が入ってくるところはなさそうです。 format string vulnerability の可能性は低そうです。 しかし build が通らないのは困るので printf(string) の修正はせざる得ません。 K&R->ANSI への change については今回は必要がなさそうです。 個人的には programmer が驚いたり警戒したりすることが少ない code が 良い program だと考えています。 (Rule of least surprise でしたっけ?) その点から FreeWnn は refactoring の余地がまだあると感じております。 ですが、今回は build を優先して、変更は最小にとどめておこうと思います。 refactoring はおいおいということで…。 -- Mitsutoshi NAKANO <ItSAN****@gmail*****> <bkbin****@rinku*****> <https://twitter.com/ItSANgo> <http://d.hatena.ne.jp/Itisango/> <https://launchpad.net/~bkbin005>
Fork