glibc 2.1.3では、ユーザーがe2fsck(8)コンパイルエラーが原因でデータ損失が発生したと文句を言うときに、リンクタイム警告を追加します。
「この
llseek
機能は危険です。代わりに `lseek64を使用してください。」これにより、警告のないコンパイルが必要な場合、関数は使用できなくなります。
glibc 2.28以降、この関数シンボルは新しくリンクされたアプリケーションでは使用できなくなりました。
この背後に隠された物語は何ですか?
答え1
問題は、glibcのllseek
ヘッダファイルに対応する宣言のないシンボルが含まれていることです。e2fsck
構成スクリプトはこのシンボルを検出し、これが機能を使用できることを意味すると仮定します。ただし、暗黙的な関数宣言が関数が期待するものと一致しないため、関数呼び出しが誤ってコンパイルされる可能性があります。特にllseek
64ビットオフセットが必要ですが、暗黙の宣言によってint
パラメータが生成されます。これにより、e2fsck
予想とは異なるオフセットで変更が行われるため、データ損失が発生します。
e2fsck
これを使用する理由は、llseek
libc5(Linuxのglibcの前身)がそれを宣言して使用可能にするからです(位置unistd.h
)。したがって、e2fsck
libc5用にビルドすると正しく機能しますllseek
が、glibc用にビルドするとビルドは成功しますが機能しません。
この問題はe2fsprogs 1.12で修正され、変更ログエントリは次のとおりです。
E2fsprogsはglibcで動作します(少なくともRedHat 5.0に付属のバージョンでは)。 llseek()が存在しなくても、ext2fs_llseek()関数はi386 ELF共有ライブラリで機能します。また、(a) llseek が libc にあること、(b) llseek がシステムヘッダファイルで宣言されていることを確認するために、明示的な設定テストを実行します. (libc開発者が以前のバージョンのlibcとの互換性の概念を理解していないという標準的な苦情を参照してください。)
llseek
コードが;を使用しようとしたときに警告するようにCライブラリも変更されました。ディスカッションはメーリングリストのアーカイブにあります。。