新着記事

2005年12月04日

F4IはLGPLを侵害しているか?その3

Is F4I in violation of the LGPL? - Part IIIより。

F4IはLGPLを侵害しているか?その3

先日の記事に、Frankから以下のコメントが寄せられた。

このコード断片は一体何をしているのか? ある公開資料で明確に定義されたデータを利用している。 ソフトウェア開発者には、これをほんの少しだけ変更する自由裁量権がある。 今までのところ、これは偶然の一致か、開発者が他人のソースコードを見てインスパイヤしたケースとも考えられる。 かの有名なLinuxの「盗まれた」Unixコード断片のように。 これはさらなる調査への招待である。つまり、私はとてもまだ動かぬ証拠を見たとは考えていないわけだ。

これは根拠のある不安であり、なんとしても本気で取り組もうと考えたので、 ここで調査を確実なものにしたいと思う。Frankへそのまま返信することにかえて、 新記事を書くだけの価値があるものと判断した。

問題の関数を完全に注釈付き逆アセンブルしたところ、LAMEのコードと99%一致した。 なぜ99%と言わねばならないかというと、両者にはわずかな相違があるからだ。 もっとも、一般的なコンパイラの最適化技術の差から論理的に説明のつくものではあるが。 これら注釈付き逆アセンブルの技術についてはこれまで必要に応じて記載してきた。

もし仮にC言語の関数が90行にわたって99%、100%まったくの偶然で一致するものだとしたら、 私のツールを使った検知能力ではとても手に負えない代物だということだ。

更新:LAMEの問題となっている関数に詳しい人々に、重大な問いかけをせねばなるまい。 LAMEのソースコードから抜粋した以下の4行を見てほしい。


if( buf[0] != VBRTag[0] && buf[0] != VBRTag2[0] ) return 0;    / fail /
if( buf[1] != VBRTag[1] && buf[1] != VBRTag2[1]) return 0;    /* header not found*/
if( buf[2] != VBRTag[2] && buf[2] != VBRTag2[2]) return 0;
if( buf[3] != VBRTag[3] && buf[3] != VBRTag2[3]) return 0;

このコード断片はbufが'Xing'と'Info'のうちどちらを含んでいるのかチェックを試みている。 基礎データ構造については知らないけれども、このチェック方法は間違っているように思える。 このコード断片は、bufが'Xing'と'Info'を連結したもの、例えば'Iing'や'Xnfo'でも通してしまうが、 それは多分動作上望ましくないだろう。これがバグであるか否か、誰が確かめられようか? これがバグとして、F4Iのコード断片にもまた同じものが存在するのだから。 問題のコードがLAMEからの盗用であるという仮説をより一層強固にするものだと言えるだろう。

更新:よし。現時刻を以て勝利を宣言させていただこう。
この一致が偶然の一致ではないことを示す議論の余地のない証拠を発見した。 LAMEのコードからGetVbrTag関数とExtractI4関数だけを抜き出し、 無料配布されているVisual C++ 2003コマンドラインツールでコンパイルしてみた。 唯一使ったコンパイラのパラメータは、最適化を最大にすべく設定した/Oxだけである。 出来上がったコードはF4IのOCXから取り出したものとバイト単位で完全に一致した。 コンパイラによる最適化由来だとする私の予測も肯定されたわけだ。 (関数のインライン展開、条件節マージ、並べ替え作業、等々)

これは以前に掲載した逆アセンブルコードと完全に一致する。 なお、私はわざわざ変数を改名したり、コメントを挿入したりはしていない。

sp Miscカテゴリ 16:43

posted by 7mm MG at 17:25| Comment(0) | TrackBack(0) | 和訳 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/10191402

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。