K.Maebashi's BBS

このコメントは yuya さんむけというわけではなくて、第三者読者様の参考分として <結合の規則> 6.2.2 識別子の結合 オブジェクトの宣言の場合 (関数には適用されない) ・記憶域クラス指定なし＝外部結合 ・static 指定あり＝内部結合 ・extern 指定あり 　「すでに宣言があって、その宣言で外部結合または内部結合が指定されている」 　　→その既存の宣言と同じ結合をもつ 　「すでに宣言があって、その宣言で無結合が指定されている」または「宣言が無い」 　　→外部結合 </結合の規則> <宣言> ・無結合の識別子の宣言が同一スコープ内に２つ以上あってはならない </宣言> ということは、外部結合の宣言が２つあってもよいということ。 6.9.2 の例 int i4; // 宣言、外部結合の仮定義 int i4; // 宣言、外部結合の仮定義 extern int i4; // 宣言、既出の結合を採用、この場合は外部結合 static int i5; // 宣言、内部結合の仮定義 extern int i5; // 宣言、既出の結合を採用、この場合は内部結合 6.9.2 に出てない例 (外部定義にならないのでわざと出していない) extern int i6; // 宣言、既出の宣言が無いので外部結合、外部定義にならない (*136) 脚注のとおり、識別子を使わなければ定義は無くてよい

なんか難しく考えすぎなのではないかと思ってきた・・・ 言語規格書は書いてあるとおりに読めばよくて、勝手に行間を解釈しては誤るよ。 <[外部定義かそうでないか]の解釈> JISX3010:2003 6.9.2 外部オブジェクト定義、で述べられている内容は要約すると ・オブジェクトの外部定義＝ファイル有効範囲と初期化子をもつ場合 ・初期化子がなく、記憶域クラスなしか static があるとき＝仮定義 ・仮定義が１つ以上あって外部定義が無い場合は、翻訳単位の終了時点で 　仮定義を =0 という初期化子を持つ外部定義と読み替える。 以上。 よってここに書いてないものは外部定義ではないっつーことだ。 記憶域クラス指定 extern をもつ宣言についてはここ 6.9.2 では記載が無いので、 外部オブジェクト定義ではない。 > 私は定義ではなく、ただの宣言である。 ここまでは正しい。というか「外部定義にならない宣言である」というべきかな。 > 定義はほかにある そんな勝手な行間を読んではいけない。これに関しては別に規定がきっちりある。 6.9 外部定義、において ・外部結合で宣言した識別子を使用している場合、プログラム全体の中でその識別子に 　対する外部定義がちょうど１つなければならない。 ・使用していない場合、１つ以下でなければならない (*136) (*136) 外部結合で宣言した識別子を使用しない場合、その外部定義は必要ない </[外部定義かそうでないか]の解釈>

774RRさん、ありがとうございます。 0. C限定の話です。 1. はい、ご紹介くださったものと同じものを入手しています(保存も……)。 2. 変数のextern宣言について[1043]で成り立つことは、 関数原型宣言(externをつけてもつけなくても同じですが)についても成り立つと思うので、関数も含む話です。 3. 処理系準拠限定の話です。[1043]の末尾の非準拠の話は、歴史的経緯の手がかりになるかも、と思って付け加えました。 で、この議論に関係する条項は JISX3010:2003 6.2.2 識別子の結合 6.9 外部定義(とくに 6.9.2 外部オブジェクト定義) になると思います。 [1043]の投稿は、[1025]に774RRさんが書かれた > extern の意味するところは[1020]で書いたとおり、結合指定 > (略) > 厳密なところは自分で JIS 言語規格書を参照してもらうとして、簡単に言うなら > extern:外部結合を指定、static:内部結合を指定 というところを読んで、その意味を考えたのがきっかけです。 確かに6.2.2にはextern宣言された識別子の結合が場合分けされて書かれていますが、 よく読むと回りの定義状況に合わせた定まり方になっており、私には(ごく自然な) *結果* と映ります。 だとすると、extern宣言はどんな「結合指定」を担っているのだろう？と疑問に思ったのです。 特に、初期化子のない外部(ブロック外)変数定義・宣言の場合、 externをつけないほうがむしろ積極的に「外部結合」を指定しているように思います。 内容は前回の繰り返しになりますが、規格書で言えば 6.9.2 外部オブジェクト定義 例1(抜粋) static int i2 = 2; // 定義，内部結合 int i2 ; // 前に内部結合をもつ定義があるため、 // 結合の不一致が生じ、6.2.2によって // 動作は未定義となる extern int i2 ; // 内部結合をもつ前の定義を参照する が該当します。

詳しい議論（重箱の隅ともいう）に入る前に確認事項をいくつか 0.この話は C 限定か？それとも C++ 限定か？ 1.言語規格書は読みましたか？今手元にありますか？ (C89 なら JIS X3010:1993 ないし ISO/IEC 9899:1990) (C99 なら JIS X3010:2003 ないし ISO/IEC 9899:1999) (C++ なら JIS X3014:2003 ないし ISO/IEC 14882:2003) 2.変数の話限定か？それとも関数も含むか？ 3.規格非準拠の処理系の話も含むか？規格書採択前を含むか？ 規格非準拠の処理系の話ならパスします（きりがないので） C/C++ 言語規格書が無いのであればお話にならないです。げっちゅしてください。 http://www.jisc.go.jp/ から*閲覧*が可能です (小細工すれば保存もゲフゲフ) 検索が効かないので役に立ちませんが、無いよりは無限大にマシです。 んで、疑問に思われる/わからないところを具体的に条項番号を挙げて話してください。

別スレッドを立てました。 externと「外部結合」については以前から私の悩みの種で、 現時点で以下のように理解しているのですが、問題がないかどうか、よろしければご意見をお聞かせください。 以下、すべてブロック外の話で、「宣言」とは「定義でない宣言」を指すとします。 extern宣言は、同一翻訳単位内にすでに定義があれば、その結合に従った宣言となります。 定義がなければ他の翻訳単位に定義があるだろうと仮定して、 それに対応する宣言になろうとします(この場合には、状況から外部結合しかあり得ません)。 このようにextern宣言の振る舞いを見ると、externは 「近いところから順に定義を探し、状況に合わせて(きわめて自然に)結合が定まる」 宣言であると考えられます。 もちろん、実際にはほとんどのケースで外部結合になり、 内部結合になるのは同一翻訳単位内にstatic定義がある場合だけですが、 これを「例外」と捉えるよりも、上記のように結合が定まると考えたほうが良いように思います。 初期化子のない変数定義・宣言を考えたとき、記憶クラス指定子をつけなければ外部結合の仮定義になりますが、 これが(他に定義があるために)宣言に成り下がった場合でも、外部結合であることは動きません。 したがって、 static int hoge = 1; /* 定義(内部結合) */ int hoge; /* 仮定義(外部結合)、ここでは宣言になるが、結合指定が定義と矛盾する */ は未定義動作になります。これに対し、2行目にexternをつけた static int hoge = 1; /* 定義(内部結合) */ extern int hoge; /* 宣言(結合は状況に応じる)、ここでは定義に従い内部結合となる */ は問題ありません(ソースを比較すると、後者のほうが「問題あり」に見えてしまいますが)。 これを「結合」という観点から見ると、「絶対に外部結合」だったものが、 externを付けることで「結合は状況に合わせる」に変わっています。 ではexternの実際の機能は何かというと、 「私は定義ではなく、ただの宣言である。定義はほかにある」ことを明示することにあります。 [1024]ひげおやじさんの > 「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。 において、「別のところ」というのが「翻訳単位外」を指しているならば、確かに誤りです。 しかし、その「誤りである理由」は、「外部結合が『翻訳単位内も含む』概念だから」ではなく、 「externが(結合とは無関係に)翻訳単位内外両方に定義を探しに行くから」ではないでしょうか。 そもそもリンケージが翻訳単位外に及ぶ(つまり外部結合)、というのと、 宣言が定義を探しに行く範囲が翻訳単位外に及ぶ(extern宣言)、というのは 分けて考えるべきだと思うのですが、皆様のご意見はいかがでしょうか？ なお、ブロック外において明らかに定義と分かるもの(関数定義や、初期化子の付いた変数定義)に externが付いた場合、外部結合になりますね(付けなくても同じですが)。 この場合はexternが文字通り「外部結合」を意味していると考えられますが、 ANSI以前はコンパイルエラーになっていたと聞いたことがあります。

>この小細工を施したヘッダを『すでに定義を書いてあるファイル』に >インクルードしているようなソースが世の中に(けっこう)存在する > >という大前提がありますよね。 えっ? …と読み返したら、yuyaさんの[1034]には確かにそう書いてありました。 (すみません、よく読んでませんでした) この小細工を使うときには、.cにはそもそも定義を書かないと思います。 .cに定義を書いたらメリットがまったくありませんので。 >>・この小細工は、(1)の問題の解決には役に立たない >えーと、これは「小細工を施してもコンパイラはチェックしてくれない」と >いう意味ではなく、「チェックしてくれるのは小細工のおかげではない」と >いう意味ですよね？ そうです。 小細工を行わないとき、方法はふたつあって、[1037]で言うところの a)defvar.cに定義を書き、extern.hに宣言を書く。 　defvar.cではextern.hを#includeする。 b)defvar.cに定義を書き、extern.hに宣言を書く。 　defvar.cではextern.hを#includeしない。 a)なら型チェックが効きますが、b)では効きません。 774RRさんがおっしゃるような、 >この小細工はexternとは同一翻訳単位外のものを取り扱うものだと >「誤解したプログラマ なら、a)はそもそも書けないと思い込んでいるから、型チェックのため 小細工を行った、というのが、私が書いた 「(1)を問題視したプログラマがこの小細工を使った」 の意図です。

どうも自分が議論について行っているつもりで 実は勘違いしているような気がしてきて不安なのですが……。 まず、この議論には この小細工を施したヘッダを『すでに定義を書いてあるファイル』に インクルードしているようなソースが世の中に(けっこう)存在する という大前提がありますよね。その上での話ですが、 > 774RRさんの説は、(1)を問題視したプログラマがこの小細工を使った、 > というものですよね。(2)はいずれにせよ問題になるんですから。 確かに宣言自体を削らずにわざわざexternだけ削っているということは コンパイラのチェックを気にしているとも考えられますが、 単に「ここではまずいから、externを削っとこう」くらいの人もいるような気がします。 誰かが(2)の目的で書いたものを見て、 主旨を誤解して使っている(で、同じことをばっちり2回書いている)というのは あり得そうですね。 >・この小細工は、(1)の問題の解決には役に立たない えーと、これは「小細工を施してもコンパイラはチェックしてくれない」という意味ではなく、 「チェックしてくれるのは小細工のおかげではない」という意味ですよね？

山奥に旅に出ているうちに掲示板が進んでました。 >この小細工はexternとは同一翻訳単位外のものを取り扱うものだと >「誤解したプログラマが」書いてたもので >言語仕様を理解していたプログラマなら書かない代物。 どうでしょうか。私が最初にコレ↓を書いた時点では、 http://kmaebashi.com/programmer/pointer.html 細かい仕様を理解していたかどうかはともかく、extern付きのとそうでないのを 同一コンパイル単位に書いてよい、ということは経験から知っていたと思いますよ (昔のことですし、証拠を出せといわれても困りますが)。 ていうか、変数定義を入れたdefvar.cとextern宣言を入れたextern.hがあったとして、 defvar.cだけextern.hを#includeしないことは容易です。 その場合嬉しくないこととしては以下の2点があって、 (1)defvar.cとextern.hの間でコンパイラのチェックが働かなくなる。 (2)似たようなことを2箇所に書かなければならない。 774RRさんの説は、(1)を問題視したプログラマがこの小細工を使った、 というものですよね。(2)はいずれにせよ問題になるんですから。 (1)の問題は、int hoge[100];とint *hoge;みたいな問題を起こすので 確かに恐ろしいんですが、(2)の問題も存在するわけですから、 (1)の問題のため「だけ」にこの小細工が使われた、というのは無理があるように 思います。 ・この小細工は、(1)の問題の解決には役に立たない(役に立つと思っている 　人がいるとしたら、Cの仕様を知らないだけ)。 ・(2)の問題の解決にはなるが、初期化子が書けなくなるしパーサ通らなくなる 　マクロの使い方なのであまり薦められたもんではない。 ということであれば同意します。

> [結合]を理解していないプログラマが[仮定義]を理解していて、 > 意識してこういうコードを書いたかという点については、俺はきわめて疑問に思う。 > たまたま実害が無かったとしても「間違っているが結果オーライ」なだけだろう。 全面的に同意します。前回もそういうつもりで書きました。 実害が出てくれりゃ勉強する機会も生まれただろうに、と。 > [1020]と[1033]のサンプルは変えてあるのだけど、ちゃんと見てるよね。 はい、ちゃんと見てますです(コメントしておらず失敬しました)。 複数のヘッダファイルをインクルードする状況では、 [1020]だと#undefしとかないと重複定義になっちゃいますね。 でもって、[1035]のようにEXTERNの名前を使い分けるなら、 わざわざHOGE_DEFINITIONだのPIYO_DEFINITIONだのを別に用意する必要はないわけですね。

[結合]を理解していないプログラマが[仮定義]を理解していて、 意識してこういうコードを書いたかという点については、俺はきわめて疑問に思う。 たまたま実害が無かったとしても「間違っているが結果オーライ」なだけだろう。 繰り返すが C++ には[仮定義]は無いのでこーいう書き方はダメ。 [1020]と[1033]のサンプルは変えてあるのだけど、ちゃんと見てるよね。 [1020]は実際には一行抜けてて #undef EXTERN が #ifdef の前に必要 [1033]は EXTERNHOGE と EXTERNPIYO と使い分けて名前がかぶらない 両者ともいちおう正しく使えば[仮定義]も重複しないようになってるつもり。

774RRさん、ありがとうございます。 「現代 C/C++ では不要」とあったので、 古い処理系でも通るようにするための小細工なのかな、 と思ったんですが、「誤解の産物」だったんですね。 誤解されたままで、このヘッダが 外部定義か仮定義のあるファイルにインクルードされてEXTERNが消えても、 それに続く部分は仮定義になるので (つまり、外部定義 + 仮定義になるか、仮定義 + 仮定義になり、 どちらにしても「外部定義がただひとつ」と等価になる) 実害はなかった、ということになるのでしょうか。

>かつてはexternが「同一翻訳単位外のみ」を意味していたのでしょうか？ かつてというのがどのくらい昔の話を意図してるのかわからないけど、 少なくともC89 (ISO/IEC 9899:1990) の文書には今と同じ[結合]の記述がある。 規格採択前の独自仕様の処理系については、もう知る必要も無いと思う。 俺は採択前の処理系も複数個実用してたけど、「外のみ」は無かったと追記しとく。 この小細工はexternとは同一翻訳単位外のものを取り扱うものだと 「誤解したプログラマが」書いてたもので 言語仕様を理解していたプログラマなら書かない代物。 あるいは[1022]前橋さんのコメントのように 宣言部と定義部で類似の記述を分散させるのを嫌ったプログラマが行っていたかもしれない。 ----hoge.h---- extern int hoge; ----hoge.c---- #include "hoge.h" int hoge; // これならここに初期値を書ける -------------- hoge の記述がヘッダとソースで２回出てくるのはミスの元という人がいる 以下のように書いておけば記述が２回必要ないというわけで ----piyo.h---- #ifndef EXTERNPIYO #define EXTERNPIYO extern #endif EXTERNPIYO int piyo; ----piyo.c---- #define EXTERNPIYO #include "piyo.h" // piyo の初期値を与える手段が無い -------------- んで [1022] に既述のごとく初期化子がうまく書けないとか問題があるんで俺はやらない。 ちなみにC++ではODRがあるので「定義にならない宣言」と「定義」は分離するのが定石。 類似の既述が２回でてくるのは仕方ない。類似は同一ではないのだから。

ご回答ありがとうございますm(_ _)m >returnで変数の値を返すときは、それがポインタかどうかに関わらず、別の場所へ中身がコピーされます。 この「returnの動作」の理解が足りませんでした。おかげさまでモヤモヤが取れました。

>以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 >#ifdef HOGE_DEFINITION >#define EXTERN >#else >#define EXTERN extern >#endif 昔のCを知らないので、教えていただきたいのですが、 かつてはexternが「同一翻訳単位外のみ」を意味していたのでしょうか？

日本語がまずかったので訂正。 >呼び出し側で返されたポインタを使って、自動変数（のあった所）にアクセスしているからまずいのです。 呼び出した関数から返されたポインタを使って、自動変数（のあった所）にアクセスしているからまずいのです。

はじめまして。 >そこに載っている関数int_to_strではポインタを返しているからまずいの >でしょうか？それとも、ポインタでなく整数値を返す場合でも、関数の >中で宣言した自動変数の値を返すことはやめた方がよいのでしょうか。 呼び出し側で返されたポインタを使って、自動変数（のあった所）にアクセスしているからまずいのです。 >たとえば、次のような関数は（int_to_strと同じ観点から見て）まずいのでしょうか。 > >int keep(int int_value) >{ > int i; > i = int_value * int_value; > return i; >} この場合は問題ありません。 returnで変数の値を返すときは、それがポインタかどうかに関わらず、別の場所へ中身がコピーされます。 自動変数のポインタを返すとまずいのは、そのポインタが指す領域がなくなってしまうからです。 int *f(void) { int a = 0; return &a; } と言う関数があったとき、 int *p = f(); printf("%p", p); /* pの値を表示する */ のようにすることは何の問題もありません。しかし、ポインタが指している領域はすでに開放されているので、 int *p = f(); printf("%d", *p); /* pが指している領域の値を表示する */ のような事はできない、と言うことです。 こんな感じでしょうか？

お世話になっております。 「C言語ポインタ完全制覇」の９７ページの補足「自動変数の領域は、 関数を抜けたら開放される！」のつながりで質問させてください。 そこに載っている関数int_to_strではポインタを返しているからまずいの でしょうか？それとも、ポインタでなく整数値を返す場合でも、関数の 中で宣言した自動変数の値を返すことはやめた方がよいのでしょうか。 たとえば、次のような関数は（int_to_strと同じ観点から見て）まずいのでしょうか。 int keep(int int_value) { int i; i = int_value * int_value; return i; } ご返答いただけると幸いです。 （なにぶん継ぎ接ぎの知識なもんで、この質問自体がまずいかもしれませんが・・・）

＞トルさん、(ぱ)さん 返信遅くなってすみません。 大変分かりやすく説明していただき、ありがとうございました！ よくわかりました。 「なぜこの関数から？？」 →まさにこの疑問でした・・・。 本当にありがとうございました！！

>「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。 こういう疑問が出てくるということは、言語規格書を読んでみていいレベルということだ 初心者向け解説書は厳密さよりもわかりやすさを優先せざるを得ないので びみょーに不正確だったりすることがある extern の意味するところは[1020]で書いたとおり、結合指定 C なら JIS X 3010:2003 6.2.2 C++ なら JIS X 3014:2003 3.5 厳密なところは自分で JIS 言語規格書を参照してもらうとして、簡単に言うなら extern:外部結合を指定、static:内部結合を指定 外部結合＝その名前が表す実体は、他の翻訳単位または同じ翻訳単位で使うことができる 内部結合＝その名前が示す実体は、同じ翻訳単位で使うことができる ということだ。

ご回答ありがとうございますm(_ _)m 変数と関数の宣言・定義の違いでの説明がしっくり来ました。 >初心者向け解説として「 extern は別のところにあるものを使う宣言」と書いてある書籍を見かけるけど >言語規格書的には大きく間違い (同一翻訳単位中にあってもかまわないので) まさにこれがもう一つ質問したかったことでした。 「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。

>グローバル変数の名前が偶然かち合ってしまう可能性があります。 (snip) >と書いてもエラーにならないと困ってしまいます。 C++ においては ODR (One Definition Rule) により、これは必ずエラーになる C ではエラーにならない (仮定義の重複を認める) という違いがあるですな。 初心者向け解説として「 extern は別のところにあるものを使う宣言」と書いてある書籍を見かけるけど 言語規格書的には大きく間違い (同一翻訳単位中にあってもかまわないので) 俺も後輩君にそういう説明したことあるし反省っすな。

>ヘッダ中で宣言＋ソースファイル中で定義することは完璧に正しい これはもちろんそうなのですが、 >以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 >#ifdef HOGE_DEFINITION >#define EXTERN >#else >#define EXTERN extern >#endif この小細工は、ヘッダとソースファイルに似たようなものを分散させたくないという面からは有効だと思いますよ。初期化子がうまく書けないとか、文法的にCのパーサを通らんようなマクロを作るなとか、そもそもそんなにグローバル変数使うなよとか、批判があるのはわかりますが。

>分割コンパイルなどで、外部で定義している変数を参照するにはexternを使う、と >よく本に書いてあると思いますが、外部の関数を参照するにはexternを >付ける必要がないように見受けられるのです。これはなぜなんでしょうか。 774RRさんのおっしゃるようにそういう約束だから…なのですが(X3010の6.1.2.2)それを言ってしまうとつまらないので、理由を考えますと。 大規模なプログラムを何人もの人で書いている場合、グローバル変数の名前が偶然かち合ってしまう可能性があります。たとえば a.c: int hoge; b.c: int hoge; と書いてもエラーにならないと困ってしまいます。この場合、それぞれの担当プログラマには、「グローバル変数の値がいつの間にか変わっている」という得体の知れないバグとして見えるはずです。 その点、「externなしで定義できるのは必ず1箇所のみ、それ以外の箇所では必ずexternを書け」という規則にしておけば、リンク時にエラーになるのでこの問題を回避することができます。 では関数の場合はどうかというと、関数名が偶然かち合ったとして、 a.c: int hoge(void) {...} b.c: int hoge(void) {...} とか書いたらどうせエラーです。 つまり、関数の場合、関数の処理を書くブロックの有無で定義と宣言の区別がつくため、わざわざexternをつける必要はない、というのが私の理解です。

そういう約束だから 関数(原型)宣言に extern も static もない場合は extern が補われると考えよう void myfunc(int); // これには extern も static も明示されてないので extern void myfunc(int); // と解釈される規則 この規則は関数の場合にのみ適用されるので、変数宣言には適用されない 以下は、言語規格書の厳密解釈なので、一読してわからなかったらスキップしてね ・関数宣言で指定できる linkage は static か extern かどちらかだけ (無指定も OK) ・ static が明示されている関数宣言は internal linkage ・ internal linkage でない関数宣言は external linkage ヘッダ中で宣言＋ソースファイル中で定義することは完璧に正しい ----hoge.h---- void hogefunc(double); // This declaration has external linkage ----hoge.c---- #include "hoge.h" void hogefunc(double d) { ... } // This definition also has external linkage 以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 #ifdef HOGE_DEFINITION #define EXTERN #else #define EXTERN extern #endif

「C言語ポインタ完全制覇」を読ませてもらっております。 その本の本筋とは外れるのかしれませんが、第５章のヘッダファイルの作成と関連 してexternでわからない点がいくつかあるので質問させてください。 ご回答いただけると幸いです。 とりあえず、ひとつお聞きします。 分割コンパイルなどで、外部で定義している変数を参照するにはexternを使う、と よく本に書いてあると思いますが、外部の関数を参照するにはexternを 付ける必要がないように見受けられるのです。これはなぜなんでしょうか。

ちょいちさん、はじめまして。 >fgets(buf, 1024, stdin) >と書いていたのを、なぜ急に >fget(buf, 1024, fp) >と変えたのですか？？ もちろんこれはトルさんから回答があったように入力元を変えるためなのですが、 「なぜこのプログラムから?」というのが疑問であるわけですよね。 確かに説明不足だったかもしれません。 理由は、ここで作っている関数input_string()は、汎用の関数を目指している ためです。 このinput_string()は、扱える行の最大長に制限があるとはいえおおむね現実的な 入力においては、長さチェックを行って長すぎる場合にはエラーまで出してくれる、 という便利な関数です。実際、蔵書管理プログラムの中でもあちこちで使われて いますし、今後別のプログラムで使うこともあるかもしれません。 今後別のプログラムで使うことがあるのなら、入力元をstdinに限定して しまったのでは汎用性が薄れます。そこで、input_string()に引数として 入力元を渡せるようにしているわけです。 これで回答になっていますでしょうか?

はじめまして。私は『C言語 体当たり学習徹底入門』はもってないんですが･･･ちょっとだけ。 fgetsの第三引数の型はFILE *で、入力先を指定します。 stdinは標準入力と結びついていますので、stdinを渡せば標準入力から入力します。 fpの方は、どこぞのファイルに結びついていますので、fpを渡せばそのファイルから入力します。 要するに、stdinをfpに変えたのは、読み込み先を変えたという事です。