K.Maebashi's BBS

皆様初めまして、ＨＮ「けろ助」と申します。 職業プログラマ歴３年と９ヶ月のまだまだへっぽこです。 前橋さんのファン歴（？）は「Java 謎＋落とし穴」発刊以来ですから丸３年くらいでしょうか。 で、いきなりですが質問なのです。 本格的なアプリケーションを作る場合、「ソースを書いてコンパイルする」だけではなく、「リリース用のファ イルセット (実行モジュールや設定ファイル等の集合) を作成する」という作業も必要になってくると思います。 そして世間一般ではこの作業を「ビルド」と言い習わしているようです (正確な定義は良く認識できていません。 コンパイル～リリース用ファイルセット作成までの、一連の作業を「ビルド」と言っている場合もあれば、個別 の作業行為を「ビルド」と言っている場合もあるからです)。 ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 プログラマにとってデータ構造やアルゴリズムと同程度に重要な話題に思えるのですが、参考になる書籍やサイ トが見つからずに困っております。 ビルドツールの使い方そのものについては充分な情報が得られるのですが…。 ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 特に Java＋ant に向いた情報を必要としています。 「自分は大抵こんな構成で作ってる」「このオープンソースの設計が参考になる」「そんなものはプログラマの 基本教養じゃ。この青二才め」等、何でも構いません。 よろしくお願いします。 個人的には、前橋さんに「本格的なアプリケーションの構築技法」の本を出していただきたいな…と思っていた りするのですが。

Perlに詳しいわけではありませんが、故あって最近Perlのソースを眺めたりも してるので、ちょっと調べてみました。 >perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 >一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 Perlで記述された関数についてはその通りでしょうが、今回のケースのsprintfは Perl組み込みの関数ですから、Cで書かれた実装部分に引数の数が渡っているかどうかが 問題では? で、5.8.6のソースから探したところ、どうもsv.cのPerl_sv_vcatpvfnが sprintfの実装のように見えます(1000行近い巨大関数。sprintfじゃあ しょうがないですが)。 void Perl_sv_vcatpvfn(pTHX_ SV *sv, const char *pat, STRLEN patlen, va_list *args, SV **svargs, I32 svmax, bool *maybe_tainted) doop.cのPerl_do_printf()から追跡すると、このsvmaxが、引数の数のように見えます。 printfかましてminiperlを再構築し、確認しましたが、実際に引数の数が渡って きているようです。 が、この関数の中でsvmaxをどう使っているか見てみると、 if (svix < svmax) { というように「svmaxを超えてないか?」というチェックは何箇所かでしてますが、 上記の箇所でもelse節はなかったりするので、そのために何も起きないんじゃ ないでしょうか。

あけましておめでとうございます。今年もよろしくお願いいたします。 しばらくごぶさたしてましてすみません。 この年末は、風邪ひいて寝込むわ、紅茶ひっくり返して太ももをやけどするわで、 ただでさえ短い正月休みの前半は寝ている間に終わってしまいました。 Webページの更新を含め、やりたいことはいろいろあったはずなので、 3が日の間にぼちぼち進めるつもりです　　　…無理かも。断酒も明けたし。 なお、正月バージョンの壁紙は、 「へなちょこ愚連隊」 http://www6.wind.ne.jp/hena/index.html からお借りしました。

>Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ インタプリタだから、ではなくて、perlの言語仕様的な問題です。 perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 このとき、Cあたりだと配列長を超えたらそのままバッファオーバーラン、Javaだと 例外が投げられますが、perlの場合は読むときはundefが返り、書くときは自動で 配列長が拡大されます。 今回の場合は、$_[2]を読もうとして返ってきたundefが文字列化されて空文字列 扱いになったわけです。

>>externで「外部にあるよ！」と宣言してるにも関わらず、 >「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 >3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。 ふむふむ。C++だとそう記述があるのですね。 ありがとうございます。

御指摘ありがとうございます。 >sprintf は「可変個引数」な関数です。 >固定な引数＝必ず必要な引数、が無いとエラーになりますが、 >可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 >原理的に不可能。 申し訳ありません。すっかり忘れていました。 （前橋さんの本などで、話題になっていたのに・・・） printf系の関数は実引数が不足しているときの動作は未定義でしたね。 >C/C++ では上記コードのエラー検出はされません。 確認せずに記述してしまいました。（VC++でも検出しませんでした） 大変お騒がせ致しました。 （件名のインタプリタとコンパイラとは一切関係ありませんでした (;_;) ）

>my $string = sprintf("%s %s %s\n", $day, $message); perl はぜんぜん知りませんが、この sprintf が C の sprintf と同じ機能と仮定して： C/C++ では上記コードのエラー検出はされません。 sprintf は「可変個引数」な関数です。 固定な引数＝必ず必要な引数、が無いとエラーになりますが、 可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 原理的に不可能。 # GNU CC では printf 系関数のフォーマット引数が文字列リテラルな場合に限り、 # 個数や形の不一致を検出してくれますが、一般的には無理。

とりあえず以下 C++ の話に限定 (ISO/IEC 14882:1998) 。 # C 規格書はウチに帰r) >externで「外部にあるよ！」と宣言してるにも関わらず、 「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。

いつも楽しく拝見しています。 久しぶりに投稿します。konです。 質問なんですが、 共通機能でログを作成する機能をPerlで作成する事になりました。 その際、ログファイルに情報を1行ずつ書くのですが 必ず最後にスペースが入って改行される現象がありました。 原因は my $string = sprintf("%s %s %s\n", $day, $message); 上記のコードで、2番目の%sの後のスペースが表示されて、3番目の%sが引数のエラー にならない事が分かりました。 Ｃなどのコンパイラ型の言語なら、コンパイルエラーになりますが Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ （strictはいれてますが、ワーニングにもなりません） Perlのマスターが言うには、”Perlはアバウトだからね”と意味不明（論理的でない？） 回答が返ってきました。私も、あまりPerlをやっていないのでとても 気持ちが悪いです。

>は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。 なるほど、そうでしたか。 私は「ブロックスコープを超えるのはなんで？」と読めたのでその理由を書き足したのです(^-^;) # とりあえず解決！？

>まぁ、コンパイラがリンク処理を行う段階でexternなんていう情報は >すっかり消えうせて関数名だけ残ってしまう。 >しかも、名前の一致する呼び出し元と実体をリンク処理しちゃう。 ここ、私の解釈が間違ってましたね・・・ 本多さんの意図はexternで「外部にあるよ！」と宣言してるにも関わらず、 同一ファイル内に同じ名前があると「外部」を見に行かなくなるってことですね。 # ブロックスコープの「外にある」という風に解釈するのが自然！？

クリスマスバージョン(柄にもなく)ということで背景をいじってみました。 イブの晩が終わったら戻そうと思います。 少し前、板ごとにCSSをいじれるようスクリプトを修正しました。 なので、以前作ったテスト掲示板↓では、古いCSSがそのまま適用されています。 http://kmaebashi.com/bbs/list.php?boardid=testbbs 板ごとに多少の紹介文をページ上部に入れられるような修正もしたのですが、 とりあえず今は時間がないので 今回の素材は以下のページからお借りしました。 http://kisetu.chu.jp/navi_fuyu_xmas.html ところで、クリスマスといえば、最近久々にアクセス記録なぞ見たのですが、 「赤鼻のトナカイ」「赤鼻のトナカイ 歌詞」という検索キーワードで この雑記↓に到達した人が最近結構いらっしゃるようです。さすがはクリスマス。 http://kmaebashi.com/zakki/zakki0009.html#xmas きっとお役には立てなかったと思います。すみませんねえ。

自己レスです。 >>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 >なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。

れぷさんへ。 > a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 > b)hoge2()の中のpiyoの呼び出しで、宣言がないので暗黙にintを返す関数として >　宣言されて、 > c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは >　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 なので、 「a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、」なのですが、 最終的には、 「c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは 　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 」 となるので、前者の文章は「完結していて」が「完結していない」という結論になります。 (チェックされていればhoge1で完結している事にはなりませんので、(ぱ)さんは完結していないと仰りたかったんだと私は解釈しております。間違ってたらごめんなさい。) という訳で(私の解釈が正しければ)、bcc32では774RRさんが仰っている > と思います。C++ と違い C の場合、K&R1 の頃の（いわゆる non-ansi C) との後方互換性を > 保つため、規格書に書かれていない（もしくは規格書が禁じている）後方互換のための機能が > いくつも有効になっている処理系がほとんどのようです。 となります。 という訳でして、hoge1()のextern宣言時では「外部関数はグローバルにあると想定するしかない」ですよね。 で、宣言が完結していていない(コンパイラが余計(?)なことをしてくれるため)ため、「外部関数はグローバルにあると想定するしかない」がhoge2にも摘要されるので、れぷさんの仰る通り、 > なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 となります。 一応念の為に書いておきます。

>　と仰っているので、C++の名前空間的な機能が無い限り衝突はされられないので、それはできないとい >う結論になると思います(少なくても私の知っている限りでは)。 そうなりますね。 実は私が反応したのはお二方の文、 　　>>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 　　>なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 だったりします。 なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 ちなみにstaticを使ってしまうと、最初のソースの記述では hoge1()もhoge2()もstaticのほうを呼び出してしまうので、 元のソースとは構成を変える必要が出てしまいますね(^-^;)

> 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 　仰っている意味が分かりました。 　ローカルextern用のpiyo()は、a.cのローカルextern用の関数定義って事だったんですね。 > 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 > グローバルextern用のpiyo()を定義したものをc.cしたとして、 > どちらのpiyo()をローカルへリンクして、もう一方をグローバルでリンクすれば良いのか、 > コンパイラこれを判断するにはどうすることが良いのでしょうか？ > b.c、c.cの関数定義はいずれにせよグローバルにおかれるでしょうし、 > コンパイラもそれを想定していると考えるなら衝突することになるのかな、なんて思いました。 >　名前空間があれば解決できるのでしょうが、Cは空間分けがザックリすぎて(^-^;) > それができないですよね。 　774RRさんも、 > C の場合は名前空間わけがざっくりすぎるし、オーバーロードは無いので、 > 結局同一名称の関数は１つしか存在し得ないわけです。では 　と仰っているので、C++の名前空間的な機能が無い限り衝突はされられないので、それはできないという結論になると思います(少なくても私の知っている限りでは)。 　ローカルのextern宣言の意味については774RRさんの仰っている通りです。 　一応念の為に書いておきますが、b.cのpiyoをa.cのhoge1専用の作業関数としたい場合にはstaticを付けて、翻訳単位を分けるという方法しかないと思います。

宣言した関数が宣言のあるブロック内でのみ有効と明示したいんでしょうね。 でも、C言語を使っていると型はコンパイル後に情報が残らないので、 同じ名前が二つ残ったら、リンクエラーになるんですね。 宣言を関数ブロックに入れるというのが、かなり異常な使い方だと思いますが。 実際、以下の様になってると宣言は何の効果も発揮しません。 ----test1.c---- #include <stdio.h> static int hoge(void) { printf("static int hoge()\n"); return 0; } int main(void) { extern int hoge(void); hoge(); return 0; } ----test2.c---- #include <stdio.h> int hoge(void) { printf("extern int hoge()\n"); return 0; } ---- % gcc -O2 -Wall test1.c test2.c % a.out static int hoge() まぁ、コンパイラがリンク処理を行う段階でexternなんていう情報は すっかり消えうせて関数名だけ残ってしまう。 しかも、名前の一致する呼び出し元と実体をリンク処理しちゃう。 だから処理内容を考えると当たり前の結果なんでしょうけど。 宣言で自分の結合先を選べるという意図があったとして、結果がこうなったら、 私の例はstaticを使ってるのでちょっと事情は異なりますが ちょっと残念に思うかもしれませんね。

C の場合は名前空間わけがざっくりすぎるし、オーバーロードは無いので、 結局同一名称の関数は１つしか存在し得ないわけです。では >int func1(void) { > extern int piyo(void); > return piyo(); >} の意図はというと、 「この extern を {} 外に出してしまうと同一翻訳単位中の他の関数から piyo() が正しく 　呼び出せてしまって警告にならない」 ことを防止することにあります。 piyo() は func1() 専用の作業関数であることを明示したい、と。 だから func2() からは piyo() を呼び出せない、ないしは、 呼び出そうとすると警告になってほしい、わけですね。 # C++ ではきっちりエラーになってくれる。 ではない？

九龍さん、はじめまして。 　3つに別けたのはa.cのコードが以下のような状況を想定しているように思えたからです。 ---a.c--- void hoge1(void) { extern void piyo(int a); // b.c内を想定 piyo(1); } void hoge2(void) { piyo(2); // c.cを想定 } 　なので、↓こういう状況を考えたわけです。 ---b.c--- // hoge1()ではAさんがくれたこっちを使おうと思った void piyo(int a) { return; } ---c.c--- // hoge2()ではBさんがくれたこっちを使おうと思った int piyo(int a) { return a; } 　この状態でb.c内にあるpiyo()をhoge1()ローカルだけに対して定義できるかというとできないですよね。 従って、hoge1()でローカルexternしたpiyo()はどこにあるのかというと、 コンパイラは「外部にある関数はグローバルに存在すると想定する」としかないのかな、と思います。 そうなると、 　　「hoge1()でローカルexternされてるpiyo()はグローバルにあるはず」 　　「hoge2()のpiyo()はプロトタイプ宣言ないけどこれも多分グローバルにあるはず」 になるので、a.cのコンパイル時に正しいpiyo()をリンクするための情報を作るには 「正しいpiyo()はどれですか？」と整合エラーを吐くしかないような気がしました。 　名前空間があれば解決できるのでしょうが、Cは空間分けがザックリすぎて(^-^;) それができないですよね。

れぷさん、はじめまして。 >例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 「ローカルextern用のpiyo()を定義したもの」とありますが、どのような意味なのか理解しかねております。 具体的にどういうソースかをお書き頂けると嬉しいのですが。

横レスすいません。 >c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは >　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 ローカルでexternするにしてもグローバルでexternするにしても、 piyo()は外部に定義あるわけですよね。 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 グローバルextern用のpiyo()を定義したものをc.cしたとして、 どちらのpiyo()をローカルへリンクして、もう一方をグローバルでリンクすれば良いのか、 コンパイラこれを判断するにはどうすることが良いのでしょうか？ b.c、c.cの関数定義はいずれにせよグローバルにおかれるでしょうし、 コンパイラもそれを想定していると考えるなら衝突することになるのかな、なんて思いました。 あー、なんかまた外したこと言ってそう(;_;)

>bcc32ですが、 > > extern void piyo(int a); > >と書いていたのを、 > > extern int piyo(int a); 一応、VC++ 6.0(SP6)でテストしてみました。 --a.c-- void hoge1 (void); void hoge1(void) { extern int piyo(int a); piyo(1); } void hoge2(void) { piyo(2); } --b.c-- int piyo (int a) { return a; } c:\cppsrc\a\a.c(11) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 となりました。 しかし、 >a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 >あまり関係ありませんが、コンパイラの警告メッセージの翻訳チームは規格書を理解して >細心の注意を払って訳しているのか、かなり疑問。 >宣言と定義は用語の意味が違うのですが、どう見ても混同していると思われます。 同感です。 私もコンパイラの警告メッセージで理解に苦しむ時があります。

>ということでしょうかね。 と思います。C++ と違い C の場合、K&R1 の頃の（いわゆる non-ansi C) との後方互換性を 保つため、規格書に書かれていない（もしくは規格書が禁じている）後方互換のための機能が いくつも有効になっている処理系がほとんどのようです。 VC++ や BCC なんかはその典型ですね。 # 関数宣言のスコープ拡大なんかはその一例。 gcc の場合、後方互換な機能が使われると警告を出すオプションがあったりしますが... あまり関係ありませんが、コンパイラの警告メッセージの翻訳チームは規格書を理解して 細心の注意を払って訳しているのか、かなり疑問。 宣言と定義は用語の意味が違うのですが、どう見ても混同していると思われます。 >エラー E2356 proto2.c 10: 'piyo' の再宣言で型が一致していない(関数 hoge2 ) >エラー E2344 proto2.c 3: 一つ前の 'piyo' の定義位置(関数 hoge2 ) 前者は正しく『宣言』ですが、後者は『定義』ではなく宣言であるはずです。 >hoge.c(7) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 これもヘン。ここは『宣言』でなければならないはずです。 >hoge.c:7: warning: implicit declaration of function `piyo' gcc の英語は正しく「宣言」と言っています。 gcc-3.3.4 の gcc/po/ja.po を見たところほぼ正しく翻訳しているようですが、 一部やはり誤訳を発見。あぁ、フィードバックしないといけないかも？

>C++ 規格書であれば 「JIS X3014:1998-3.3.2 局所的な有効範囲」で、 >ブロック内に宣言された名前はそのブロックに局所的である。 >と書かれています。実際以下のコードはコンパイルエラーです。 C でも、6.1.2.1 を見る限り、ブロック内で宣言された識別子のスコープは ブロック内ですから、プロトタイプ宣言もブロック内だけで有効と考えるのが 自然なように思います。 ただ、ふたつのコンパイラで、単純にそうとは言えない動きをしているので、 どこか別に規定があるのかと、昨晩は規格書をひっくり返していたのでした。 >んで、上記を hoge.c とした場合の挙動ですが >bash-3.0$ hppa2.0w-hp-hpux11.00-gcc-3.3.4 -Wall -c hoge.c >hoge.c: In function `func2': >hoge.c:7: warning: implicit declaration of function `piyo' これはプロトタイプ宣言がない場合の通常の挙動ですよね。 だから、gccでは、ちゃんとブロックでスコープが終了していて、 C++ではだめなのは、C++ではそもそもプロトタイプ宣言がないことを許さないからで。 bcc32ですが、 extern void piyo(int a); と書いていたのを、 extern int piyo(int a); にしたら通りました。 推測するに、 a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 b)hoge2()の中のpiyoの呼び出しで、宣言がないので暗黙にintを返す関数として 　宣言されて、 c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは 　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 ということでしょうかね。

申し訳ございません。コンパイラの警告レベルを4に上げるの忘れてました…(面目ないです)。 ちなみに、警告レベル3では何も出ませんでした。 >cl -W4 -Za -c hoge.c だと >hoge.c(7) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 >となるのでやはりブロックスコープなのが本来みたいですね。 Microsoft言語拡張機能の無効スイッチですね(全然気にしてませんでした。これからは切るようにします…)。 確かに、これを見るとブロックスコープなのが本来の仕様みたいですね。

おっと自己レス。 cl -W4 -Za -c hoge.c だと hoge.c(7) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 となるのでやはりブロックスコープなのが本来みたいですね。 ブロックスコープを超越して大域に関数宣言が有効になるのは（互換性のための）拡張機能、と。 # 規格書を要確認だなこりゃ。

C 規格書はウチに帰らないと無いのでアレげですが C++ 規格書であれば 「JIS X3014:1998-3.3.2 局所的な有効範囲」で、 ブロック内に宣言された名前はそのブロックに局所的である。 と書かれています。実際以下のコードはコンパイルエラーです。 ---hoge.cpp--- int func1(void) { extern int piyo(void); return piyo(); } int func2(void) { return piyo(); } ---EOF of hoge.cpp--- んで、上記を hoge.c とした場合の挙動ですが bash-3.0$ hppa2.0w-hp-hpux11.00-gcc-3.3.4 -Wall -c hoge.c hoge.c: In function `func2': hoge.c:7: warning: implicit declaration of function `piyo' Microsoft Visual C++ 6.0SP6 だと cl -W4 -c hoge.c hoge.c(2) : warning C4210: 非標準の拡張機能が使用されています : 関数にはﾌｧｲﾙ ｽｺｰﾌﾟが与えられています。 hoge.c(7) : warning C4217: 非標準の拡張機能が使用されています : 以前のブロｯクでの関数宣言です。 となりました。 やはり言語規格がスコープ詳細等を定めていないようです。 # IE6 でも Acrobat Reader を uninstall してから JIS 閲覧するとゲフガフ # って検索が効かない文書なので、むりくり保存してもあまり役に立たない鴨。

774RRさん、度々申し訳ありません。 >リンク先の１２番の解説を文字通りに解釈してください。 >仮定義（初期化子なし定義）だけがあって、初期化子あり定義が無い場合、 >翻訳単位のEOFに達した時点で仮定義は定義となります。 >--hoge.c-- >int x; // 仮定義 >int x; // 仮定義：何回仮定義が現れても（既存の宣言に反しない限り）問題ない >int x; // 仮定義 >--EOF of hoge.c-- >この時点で int x=0; と定義されたことになる。 > >>上記の場合だと、b.cのint a;が仮定義なので、 >この文章はある意味YES、ある意味NO。確かに int a; は仮定義ですが、既に述べたとおり >翻訳単位 (b.c) の EOF に達した時点で、仮定義は「仮ではない『定義』」になります。 >よって提示の例では a.c b.c ともに変数 a が定義されています。 >そこではじめてリンク先１３番目の解説が効いてきます。 > >>a.cで定義されているint a = 1;のオブジェクトとまとめられたと言うことで >「仮定義だからまとめられた」のではありません。 >「C では、定義が複数ある場合の挙動が定められていない」（未定義動作） >→「エラーにするのも、定義を１つにまとめるのも処理系の実装次第」 >→→「多くの C 処理系では定義を１つにまとめちゃう」 >となっただけです。 > >>b.cのint a;がextern int a;と解釈されている訳ではないという解釈で宜しいでしょうか？ >コンパイラは int a; を勝手に extern int a; と解釈しません。 >そのへん関数宣言と変数宣言で文法が違う場所です。 なるほど。理解できました。 ご丁寧な解説、ありがとうございます。

リンク先の１２番の解説を文字通りに解釈してください。 仮定義（初期化子なし定義）だけがあって、初期化子あり定義が無い場合、 翻訳単位のEOFに達した時点で仮定義は定義となります。 --hoge.c-- int x; // 仮定義 int x; // 仮定義：何回仮定義が現れても（既存の宣言に反しない限り）問題ない int x; // 仮定義 --EOF of hoge.c-- この時点で int x=0; と定義されたことになる。 >上記の場合だと、b.cのint a;が仮定義なので、 この文章はある意味YES、ある意味NO。確かに int a; は仮定義ですが、既に述べたとおり 翻訳単位 (b.c) の EOF に達した時点で、仮定義は「仮ではない『定義』」になります。 よって提示の例では a.c b.c ともに変数 a が定義されています。 そこではじめてリンク先１３番目の解説が効いてきます。 >a.cで定義されているint a = 1;のオブジェクトとまとめられたと言うことで 「仮定義だからまとめられた」のではありません。 「C では、定義が複数ある場合の挙動が定められていない」（未定義動作） →「エラーにするのも、定義を１つにまとめるのも処理系の実装次第」 →→「多くの C 処理系では定義を１つにまとめちゃう」 となっただけです。 >b.cのint a;がextern int a;と解釈されている訳ではないという解釈で宜しいでしょうか？ コンパイラは int a; を勝手に extern int a; と解釈しません。 そのへん関数宣言と変数宣言で文法が違う場所です。

>それをやっちゃうと、swap(float *a, float *b)のような関数で困りますし。 なるほど。仰られる通りです。 >もともと、プロトタイプ宣言なんて書かなくても(警告は出ても)動きますから、 >結合はされるとしても、プロトタイプ宣言の有効範囲は微妙な問題のように >思います。 > >以下のソースをbcc32でコンパイルしたところ、 > >void hoge1(void) >{ > extern void piyo(int a); > > piyo(1); >} > >void hoge2(void) >{ > piyo(2); >} > >こんなエラーが出ました。 >エラー E2356 proto2.c 10: 'piyo' の再宣言で型が一致していない(関数 hoge2 ) >エラー E2344 proto2.c 3: 一つ前の 'piyo' の定義位置(関数 hoge2 ) > >hoge2のブロックの先頭に「extern void piyo(int a);」を入れると >ちゃんと通るので、少なくともbcc32においては、hoge1()内部の宣言がそのまま >hoge2()内部で有効になっているというわけではないようです。 > >この件について規格書になにか書いてないかとぱらぱらめくったのですが >見つけられませんでした。 わざわざ規格書まで調べて頂き有り難うございます。 と、ゆうことは処理系依存って事なんでしょうね…。