val it: α → α = fun

PHP 5.3.7のcrypt関数には深刻な問題があった、という話の詳細については徳丸浩氏が紹介しているのでそれを読んでいただくとして、どうしてこうなったのか、ということについてPHPの作者、Rasmus Lerdorf氏がGoogle+に投稿している。これも、どうしてこうなったの部分は徳丸さんが紹介しているが、それ以外の部分に興味があったのでちょっと紹介しておこう。

こういった問題が発覚すると、テストとかQAとかしてなかったのか、という疑問がわく。で、そういう質問とかをされているわけで、返事にいわく、テストはしていたけど、今回はそのままリリースしたのだという。そんなのってあるのか？

+Lorenz H.-S. We do. See http://gcov.php.net
You can see the code coverage, test case failures, Valgrind reports and more for each branch.
The crypt change did trigger a test to fail, we just went a bit too fast with the release and didn’t notice the failure. This is mostly because we have too many test failures which is primarily caused by us adding tests for bug reports before actually fixing the bug. I still like the practice of adding test cases for bugs and then working towards making the tests pass, however for some of these non-critical bugs that are taking a while to change we should probably switch them to XFAIL (expected fail) so they don’t clutter up the test failure output and thus making it harder to spot new failures like this crypt one.

コードカバレッジ、テストの失敗、valgrindのレポートなどをきちんととっている。だけど、テストの失敗を調査せずにリリースをしてしまったというわけだ。やっていても見なければ意味がない、という残念な結果になっているが、どうしてそうなのかというのが面白い。つまり、バグレポートが上がってくると、その時点で(直す前にまず)テストケースを足していくという開発スタイルなのだと。したがってテストの失敗が無数にあるのが常態化していたというわけだ。

このスタイルを崩すつもりはないが、バグレポートによる失敗ケースは基本的に失敗するのが前提なので、これをXFAIL(expected fail)なんかに変えることで、失敗することが期待される部分と、本当のバグが分離できるだろうとのこと。

何が言いたいかというと、別にテストがされてないわけではないし、単にテストを無視してリリースしたといった残念な話でもない。それなりの哲学を持った開発スタイルをしていたわけで、ただこういう回帰バグをあんまり想定した作りになっていなかった。今後どうしたいかも一応視野に入っている。といったあたりが興味深いなあと。

—

余談ですが、徳丸さんの紹介しているglibcの作者Ulrich Drepper氏は厄介な人物として知られていて、glibcにstrlcatを追加することをかたくなに拒否し those who are using strcat or variants deserved to be punished. などと述べています。確かに彼の言うとおり、長さがわかっているのならmemcpyなどを使えばいいわけで、今回は彼が正しかったわけですが。