namazu-dev(ring)

[Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>]

knok@xxxxxxxxxxxxx (NOKUBI Takatsugu) wrote:

>> # 野首さんが vsnprintf を導入したのをきっかけに気づきました。
>> # (IRIX 6.3 で make が通らなかった)
>
>  なるほど、vsnprintfが無い環境もあるんですね... 最近、buffer overflow
>由来のsecurity bugがあちこちで報告されているので、特にauto変数を使うよ
>うな場合には*nprintf, strn*など長さを制限した関数を可能な限り使うこと
>とが重要だな、と思っていたところなのです。

うーん、 buffer overflow の危険性にきちんと対処するのは大変
ですね。library化にあたって、メモリ管理を再検討する必要があ
ります。 (libnmz を使った server を実装したりするかもしれな
いし)

現在は次のような安易な方針をとっています。

  * ユーザの入力 (検索式など) に対して長さ (byte 数) の制限を行う
    - 入力の長さが制限の値より大きければその時点で警告を出して終了する

  * ユーザの入力を記録するために制限の値より大きい配列を確保している

理屈ではこれで大丈夫のはずなんだけど、かなり怪しいです。もと
もと、「実行したら検索をしてすぐ終了する」プログラムのつもり
だったので、メモリ管理はいいかげんです。

[namazu-dev 105] で報告されているように、検索処理を繰り返し
ているうちに、プロセスが緩やかに膨張していってしまう問題があ
ります。

どこかで free()を忘れているのが原因だと思うんだけど、どうやっ
て検出すればいいのだろう…。ご教示くださいませ > どなたか

  ...

ところで、ついさきほど EUC-JP の文字列を ISO-2022-JP に変換
する euctojis() なる関数を作りました。EUC-JP から 
ISO-2022-JP への変換では文字列が伸びるのできちんと扱うと大変
です。

そこで、安易に「あらかじめ充分に大きな領域を確保しておくべし」
という前提で実装してしまいました。こんなの言語道断ですね。;-)

# とりあえず LANG={ja_JP.iso-2022-jp,=ja_JP.sjis} に応じて出
# 力を切り替えられるようになりました。

昼食後にその辺の処理を実装し直します。

-- Satoru Takabayashi
C言語はやっぱり嫌いだ…