少し前ですが、apacheのMLに以下のメールがありました。

• http://mail-archives.apache.org/mod_mbox/httpd-dev/200805.mbox/%3c200805141444195002867@case.edu%3e

apacheのソースコードを静的解析して、バグ(らしいモノ)を見つけたという投稿です。apacheのソースは、保守的かつ慎重で、非常に多数の目が通っています。今さら静的解析ツールでバグを見つけたとしたら驚きます。

メールから引用します。

The 6 bugs can be categorized into the following 2 groups:

Category-1: missing of a check of the return value of a function A function may return an error code such as 0, -1 or NULL to indicate that an error occured inside of a function. We've found several potential bugs where a check of the return value is likely to be missing for certain functions.

Category-2: missing of a function call This normally happens when a function call is missing in a set of function calls that always need to be invoked together, for example, malloc() and free().

前者(category-1)は、たいしたことありません。関数の戻り値を無視するコードなら、(成熟したソフトでも)珍しくはありませんし、静的解析で見つけたと聞いても驚きません。

後者(category-2)は典型的なバグで、ある条件下では発見が難しいバグです。これに関するバグをツールで見つけたとしたら、たいしたものです。

理想的には、このように呼び出し側が順序を気にして呼ぶAPIを無くすべきですが、現実に無くすことはできません。局所的には、設計の工夫や言語の持つ機能で可能ですが、全てを無くせると思うのは幻想です。GCを持ったJavaでmalloc()/free()相当のペアを無くせても、close()相当のメソッドを完全に追放できないことからも分かります。Rubyのブロックでclose()相当の呼び出しを隠蔽できることを知っている人は、まだ幻想を持つかもしれませんが、解決できるのは局所的な場合のみです(解決できるのはC++のRAIIのテクニックでカバーできる部分と同程度)。

結果的には、category-2として見つけたふたつのバグらしいものはバグでは無いという結論でした。apacheのコードの場合、メモリプールの解放時にコールバック関数を登録できて、そこで暗黙にリソースの解放をできます。今回、ツールが指摘した箇所は、そういうコードだったようです。静的解析ツールの言うがままに解放処理を入れてしまうと、想定より早い解放のために誤動作(たぶんクラッシュ)します。

ある程度の規模のソフトウェアの場合、こういう風に、局所的にコードに見えている部分だけではなく、より上位のメタ知識が暗黙に要求されるコードがあります。これは、プログラミングで最も難しいことのひとつです。逆に言えば、暗黙の要求が少ないコードほど、可読性が高いコードであり、多くのプログラマが書きたいと思うコードでもあります。

今回は残念な結果でしたが、静的解析ツールで「We found a potential rule requiring that the ap_destroy_sub_req() be executed to release the object returned by ap_sub_req_lookup_uri()」を発見できるのはクールだと思いました。