Linux関連の話題を扱うニュースサイト「LWN.net」の記事です。発端は、Fedora上である音楽サイトを開いたところFlashによるmp3プレーヤにて正常に再生されなかった、というバグチケットになります。そしてLinux用のFlashに使われているライブラリglibcのmemcpy関数に原因があることがわかりました。

memcpy関数はメモリ領域をコピーする関数で引数としてコピー元とコピー先を指定します。そしてドキュメントにも書かれているのですが、コピー元とコピー先それぞれの領域が重なってはいけない制約があります。しかし、場合によっては領域が重なっていても結果的にうまく処理されることもあり、今回のFlash Playerもそのレアケースに相当していました。そして、glibc開発チームにより64ビット向けCPUのパフォーマンス向上のためにmemcpy関数内部の実装を変更したところ、制約を守っていなかったFlash Playerにて今回の問題が発生しました。

この問題について、Linuxの生みの親であるLinus Torvalds氏も登場し熱く議論されています。意見は大きくglibcチーム側とLinus側の2つに分かれており、glibcチームは「仕様として明記しているので、誤って利用するほうに問題がある」と至極もっともな主張をする一方、Linus側は「Linuxカーネルは『no regression』ルールを厳守しなければならず、よほどの理由がないかぎり利用側に影響を与える変更は行ってはならない」とglibcチームを非難しています。

たしかにmemcpyのような非常に広く使われる関数を変更することは、利用側に多大な影響を与えてしまうため慎重にならなければいけないことも理解できます。Flashのようなメジャーなアプリケーションでさえミスをしてしまうのですから、同じミスをしているケースはほかにも山ほどあることでしょう。ただ、今回の変更により特定CPUにおいてパフォーマンスが数倍も向上しており、多くのライブラリやアプリケーションにてmemcpy関数が利用されていることを考えると、全体的に大幅な速度向上が見込めることも無視してはいけません。間違った実装を気にすることで、正しい実装の改善を阻害してしまうのはもったいない話のように思えます。

はたして「仕様を間違って利用している側のことも考慮して、変更に慎重にならなければならないのか⁠」⁠。これは非常に難しい問題であり、決して他人事ではありません。私はこれまでglibcチーム側の意見で疑いなかったのですが、この記事で違った考えもあることに気づかされました。

URL：http://lwn.net/Articles/414467/