テストの作成

今、libHaruというオープンソースのライブラリに、bmpファイルの読み込みを実装しています。自分で用意したテストデータは問題なく取り扱えるのですが、｢不適切な連長圧縮がされたファイル｣(※)を作成するソフトが見当たらず、テストが十分にできていません。このような特殊なデータを作成するソフトをご存じの方、またはこの手のデバッグのノウハウをお持ちの方、ご鞭撻よろしくお願いいたします。

参考URL: http://www.ruche-home.net/program/bmp/rle

※参考資料中の｢エンコーダは、このような～の扱い方をするべきではない。｣というような、不適切な処理がされているファイルのこと。GIMP、Bmp To Bmp、2種類のソフトで試したものの、どちらも優秀なソフトで不適切な処理をしなかった。

行動規範の内容に同意します

回答2件

ベストアンサー

このような特殊なデータを作成するソフト

特殊データを生成するツールを作る（既存ツールを改造するなど）のが近道と思いました。

またはこの手のデバッグのノウハウをお持ちの方、ご鞭撻よろしくお願いいたします。

ファズ・テスト(fuzz testing)の一種と言えます。最も単純（あまり効率が良くない）なのは、正しいデータをランダムに書き換えてテストケースを作ることです。しかし質問中にある確認項目を見る限り、意図的にそのようなデータを作り出さないと有効な試験とならない気がします。

他回答へのコメント：どうしてもソフトなければ、その機能を削除することも考えてます(対応する必要性自体なくなるから)

上記表現について、個人的に少し気になったのでコメントしておきます。

非圧縮BMPにおける行データは4バイトの整数倍のサイズに揃えなければならなかったが、RLEにおいてはそのような制約はなく、エンコーダは有効なピクセル数分だけ圧縮すればよい。

これは「RLEでは無視される/すべきバイトは存在しない」と言っているだけですから、デコーダ側では何も気にしなくて良いはずです。仮に、エンコーダがこの条件に従わなかった場合、単にデコード画像が斜めに崩れるだけです。

エンコーダは、このようなEOLの扱い方をするべきではない。
エンコーダは、このようなEOBの扱い方をするべきではない。

データの早期打ち切り（データが足りない）ケースは比較的対応が簡単ですし、保護機構の一種ですから実装だけはしておいたほうが良いと思います。

意図する場合を除き、エンコーダは位置移動情報を利用するべきではない。

（これは少々厄介かもしれません。そもそも"位置移動情報"を生成するRLE BMPエンコーダが存在するのかも含め、私には知識がありません。）

投稿2016/09/09 12:43

yohhoy

総合スコア6191

majiponi

2016/09/09 13:33

補足すると、そもそもRLEを作るソフト自体が少ない中、さらに特殊な事態にまで完璧に対応する必要に、疑問が出てきたのです。ライブラリは、多機能であるだけではなく、コンパクトで、高速である必要もありますから。特殊なエンコーダーがそもそも出回っていなければ、実装せず、万一の場合には「対応していない」とエラーを出すだけでもいいような気がするのです。なので、エンコーダーが存在するか、という点を質問しました。

yohhoy

2016/09/09 13:52

完璧に対応する必要はありませんが、少なくとも防衛的プログラミングは必要ですね。悪意を持った攻撃者が攻撃データを入力可能なシステムの場合、防御機構がない場合はシステムの脆弱性につながります。この辺りは、RLEデコーダが実際に使われるユースケースやセキュリティ要件、実装言語にあわせて判断されたほうがよいでしょう。

majiponi

2016/09/14 07:07

しばらく様子を見ましたが、メジャーなソフトでは、なさそうです。機能としてどこまで対応するかは、libHaruのコミュで継続審議することにしました。お二方とも、ありがとうございました。

行動規範の内容に同意します