私は標準Cライブラリの内部作業に興味があります。私は可能な実装に関する良い本を見つけました - しかし、標準ライブラリ全体と、標準ライブラリのこれらの標準の定義であるPOSIXのような標準のより深い説明を探しています。C標準ライブラリの内部作業
Cドラフトは非常に参考になりますが、読むのにはあまり役に立ちません。このトピックに関する他の文献はありますか？
アルベル「Cでは
良い出発点はPOSIXでしょう。 POSIX 2008仕様は、ここにオンラインで利用可能です：
http://pubs.opengroup.org/onlinepubs/9699919799/
これは、Cの標準よりも多くのアクセス（時にはあまり厳格）だと、ちょうどCの標準よりも多くをカバー、すなわちの標準化された部品のほとんどUnixライクなシステムの標準ライブラリ。
実装に興味がある場合は、まず、POSIX記述の動作が、カーネル実装とユーザー空間libc実装の間で（必要かつ実用的な理由により）分割されることに注意してください。 POSIXにおける多数の関数（およびC標準からのいくつか）は、単に「システムコール」のためのラッパー、つまり要求を処理するためのカーネル空間への遷移にすぎません。いくつかのlibc実装では、これらのラッパーを見つけることさえ困難です。それらはビルドスクリプトによって自動的に生成されるか、または単一のアセンブリ言語ファイルに統合されることが多いからです。標準ライブラリの
主要な（非カーネルコードのかなりの量）サブシステムは、一般的に：
open,readなどのファイル記述子IO関数に基づいています。cloneとfutex syscallsに基づいて独自の実装を提供しています。あなたがソースを読み始めたい場合は、私はglibcので始まらないことをお勧めします。非常に大きく、扱いにくいです。 glibcを読むには、多くのコードがsysdepsツリーの下に隠れていて、適用可能なシステムの多様性に基づいて編成されていることに注意してください。
Dietlibcは非常に読みやすいですが、ソースを読む場合は、一般的なCプログラミングミス（例：int、size_tが必要な場合、オーバーフローをチェックしないなど）があることに注意してください。これを覚えておけば、多くの可能性のあるエラーや失敗を無視すると、コードを非常に単純にする傾向があるので、悪い選択ではないかもしれません。
これは、libcのソースを読むために、私はBSDまたはmusl（免責事項：私はmuslの第一著者であるため、ここで少し偏っている）のいずれかをお勧めします。 BSDには、カーネルスペースコードも非常にシンプルで読みやすいという利点があります。そのため、システムコールの反対側でカーネルコードを読みたい場合も、それを行うことができます。
こんにちは ありがとう、この面白い解答（およびブロック解除）です。私が気づいたPOSIXの仕様から少し読んだところで、このドキュメントは標準の定義に焦点を当てているので、Cの標準よりもはるかに読みやすくなっています。 私にとっては、BSDのソースページ/ドキュメントとmusl-libraryプロジェクトは、2つの良い出発点です。これらのライブラリのシステムコールバックエンドも面白いです。 Albertus – swaechter
C stdioとC++ iostream_の統合された実装 - 独自の 'iostream'実装を提供する' g ++ 'はありませんか？ –
@ Maxim：はい、クラスのバイナリレイアウトがglibc stdioの構造体のバイナリレイアウトと同じになるように設計されています。この場合、同じオブジェクトが両方のオブジェクトに使用されます... –
：リファレンス・マニュアル、第5版 "Harbison & Steele、本書の第2部はC標準ライブラリ専用です（第2部：10-24章）。
C99の根拠文書はCライブラリをカバーしていないが、ANSI C89理論的根拠は、文書のコピーはここにあり、その第4章で説明します
こんにちは 返事をありがとう、C89の "定義"についての話題は良い助けです。 – swaechter
もう一度開封してください。これを一方的に終わらせることは、モデレーターの力を乱用することでした。私はこの質問が完全に合理的で、SO形式で答えることができると確信しています。実際、私は閉会の不幸な一方的な決定によって投稿からブロックされた答えを持っています。 –
@R ..：右の質問は今開いているようです。通知を受けて質問が再開されたことを確認してください。） – cha0site
@ cha0site：ありがとう！ –