博士

ロボ子、今日のITニュースはC標準ライブラリの比較じゃ！musl, uClibc, dietlibc, glibcの四天王について語るぞ。

ロボ子

興味深いですね、博士。それぞれのライブラリで、プログラムサイズに大きな違いがあるようですが。

博士

そうじゃ！最小のstatic Cプログラムを見ると、muslが1.8k、dietlibcが0.2k、uClibcが5k、glibcが662kじゃ。glibc、デカすぎ！

ロボ子

glibcは機能が豊富な分、サイズも大きくなるのは仕方ないのかもしれませんね。でも、dietlibcの0.2kは驚異的です。

博士

じゃろ？でも、サイズだけじゃ判断できないぞ。リソース枯渇時の挙動も重要じゃ。例えば、スレッドローカルストレージが枯渇した時、muslはfailureを報告するが、uClibcとglibcはabortする。

ロボ子

failureを報告する方が、プログラムの安定性には繋がりそうですね。

博士

その通り！性能面ではどうじゃろうか？Tiny allocation & freeでは、glibcが最速だが、文字列長(strlen)ではmuslがuClibcより速い。

ロボ子

用途によって最適なライブラリが異なると言えそうですね。ABI互換性はどうでしょうか？

博士

muslは安定ABIを誇り、後方互換性もある。glibcも同様じゃ。しかし、uClibcはそうではない。

ロボ子

互換性は重要ですね。ライブラリのアップデートで既存のプログラムが動かなくなるのは避けたいです。

博士

アルゴリズムも違うぞ。部分文字列検索(strstr)では、muslとglibcがtwowayアルゴリズムを使うが、uClibcとdietlibcはnaiveなアルゴリズムじゃ。

ロボ子

アルゴリズムによって性能が変わってくるんですね。セキュリティ面ではどうでしょうか？

博士

mallocSafe UTF-8デコード、スタック破壊保護、ヒープ破壊検出は、musl, uClibc, glibcが対応しておる。dietlibcは一部対応しておらん。

ロボ子

セキュリティは重要です。特に、外部からの入力を扱う場合は、脆弱性がないか注意する必要がありますね。

博士

ライセンスにも注目じゃ。muslはMITライセンス、uClibcはLGPL 2.1、dietlibcはGPL 2、glibcはLGPL 2.1+ w/exceptionsじゃ。

ロボ子

ライセンスによって、利用できる範囲が変わってきますね。プロジェクトの要件に合わせて選ぶ必要があります。

博士

ふむ。しかし、ロボ子よ。これだけ色々あると、どのライブラリを選べば良いか迷うのう。

ロボ子

そうですね。結局は、プロジェクトの要件、性能、サイズ、セキュリティ、互換性、ライセンスなどを総合的に考慮して判断するしかないですね。

博士

じゃな。ところでロボ子、これらのライブラリの中で、一番ダイエットが必要なのはどれだと思う？

ロボ子

それはもちろん、glibcですね！