reopening stdout
Shinji KONO
そういえば、標準入出力を切替える、
FILE *obuf;
fclose(stdout);
if ( (obuf = fopen(ccout,"w")) == NULL ) printf("error\n");
printf("test\n");
ってコードなんですけど、Linux と BSD で挙動が違うんだけど、
こんなものだっけ?
freopen を使うってことなんでしょうけど、前には動いていたよう
な気もするし...
もっとも、printf では stdout に書き出すんだろうから、fclose(
stdout)で書き出して出力されないってのは、ある意味で正しいん
だよね。なんで、いままでおかしいと思わなかったんだろう?
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
Kazuo Fox Dohzono
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> if ( (obuf = fopen(ccout,"w")) == NULL ) printf("error\n");
> printf("test\n");
>
> ってコードなんですけど、Linux と BSD で挙動が違うんだけど、
> こんなものだっけ?
"error\n" の方だとすると (ですよね?), そんなものです.
| 7.19.6.3 The printf function
…
| [#2] The printf function is equivalent to fprintf with the
| argument stdout interposed before the arguments to printf.
| J.2 Undefined behavior
…
| -- The value of a pointer to a FILE object is used after
| the associated file is closed (7.19.3).
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
Shinji KONO
In article <b15o00$1173$1...@news2.rim.or.jp>, doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes
>> if ( (obuf = fopen(ccout,"w")) == NULL ) printf("error\n");
>> printf("test\n");
>"error\n" の方だとすると (ですよね?), そんなものです.
いや test の方です.... ( そういば、ここは fprintf(stderr であるべきだな)
>| J.2 Undefined behavior
>| -- The value of a pointer to a FILE object is used after
>| the associated file is closed (7.19.3).
これは、その通りなんだけど、
close(1);
open(...);
で、切り替わるんだから、
fclose(stdout);
fopen(file_name,"w");
で切り替わって欲しいかナット。実際、BSDでは切り替わっていたので。
で、
stdout = fopen(file_name,"w");
は、BSDではエラーになってしまうと。(#define stdout &fbuf[1])とかだから。
Masamichi Takatsu
記事 <1219.10...@insigna.ie.u-ryukyu.ac.jp> で
Shinji KONOさんは書きました
> close(1);
> open(...);
> で、切り替わるんだから、
そもそも、これも保証されないんじゃないですか?
open が未使用の中で最小の記述子を返すなどとは規定されていなかったかと。
dup の方は最小のものを返しますから、
fd = open(...)
close(1);
dup(fd);
した時は、まあ確実に1番に割り当てられるとは思います。
(本当に確実を期すなら、dup2を使うべきでしょう)
でもって、
> fclose(stdout);
> fopen(file_name,"w");
こちらが動いているのはラッキーだと思うべきでしょう。
ライブラリの実装として、使い終わったバッファを再利用するのか、
新たにバッファを確保するのか、という問題ですよね。
これを期待するのは、
p1 = malloc(100);
free(p1);
p2 = malloc(100);
でp1==p2となることを期待するようなものだと思います。
PROJECT TEAM ＤｏＧＡ 高津正道 ta...@doga.jp
TBD0...@nifty.ne.jp
PROJECT TEAM DoGAのホームページ → http://doga.jp/
1月28日(火) 今日のマーフィーの法則 [マーフィーの自動車修理の法則]
どんなにささいな修理でも、50ドル以上はかならず請求される。
Shinji KONO
まぁ、動かない実装があるのはわかったので、今後は止めようと思
ってます。
In article <b162s4$2dvm$1...@maha2.doga.co.jp>, Masamichi Takatsu <ta...@doga.jp> writes
>open が未使用の中で最小の記述子を返すなどとは規定されていなかったかと。
うーん、そんなことされると結構動かなくなるプログラムがあるん
じゃないかと... でも、この方法を読んだのは OS-9 (Macじゃない
奴)のマニュアルだからなぁ。
> close(1);
> dup(fd);
>した時は、まあ確実に1番に割り当てられるとは思います。
>(本当に確実を期すなら、dup2を使うべきでしょう)
それだとclose(fd)が余計にいるなぁ。まぁ、ほとんどの場合 close
する必要はないんでしょうけど。
>> fclose(stdout);
>> fopen(file_name,"w");
>こちらが動いているのはラッキーだと思うべきでしょう。
>ライブラリの実装として、使い終わったバッファを再利用するのか、
>新たにバッファを確保するのか、という問題ですよね。
動かないものの方が多いってことなのかな。といいつつ、BSD, Sun
OS, Solaris, BSD/OS と BSD系列でしか動かしてなかったんだけど。
Mac OS X でも、
#define stdin (&__sF[0])
なんです。これだと、fclose/fopen で切替えられます。おそらく、
それを意識した実装なんだと思う。
でも、
extern FILE *stdout;
ってのは、ちょっと新鮮でした。Linux でも前は動いていたような
気もするんだけど、錯覚だったんだろうな。もちろん実装によるん
だけど、FILE構造体をいちいちmalloc/free するのが良い実装とも
思えない。どうせ一段indirectが入るかどうかでしかないんだけど、
getchar() とかの最適化には影響するんじゃないかなぁ。
そういえば、前の malloc/free の議論で fopen して fclose しな
いで exit するのはどうだという議論もありましたね。
ku...@gssm.otsuka.tsukuba.ac.jp
ta...@doga.jpさん:
> そもそも、これも保証されないんじゃないですか? open が未使用の
> 中で最小の記述子を返すなどとは規定されていなかったかと。
どこで、ですかね。Solaris 2.6のmanページではそれが保証されると
書いてあります。
POSIXではその保証を削除したのかな。 久野
P.S. fopen/fcloseはそんな保証聞いたことないけど。
l...@uni.sony.co.jp
ku...@gssm.otsuka.tsukuba.ac.jp writes:
>
> 久野です。
>
> ta...@doga.jpさん:
> > そもそも、これも保証されないんじゃないですか? open が未使用の
> > 中で最小の記述子を返すなどとは規定されていなかったかと。
>
> どこで、ですかね。Solaris 2.6のmanページではそれが保証されると
> 書いてあります。
Solaris9のmanでも
System Calls open(2)
NAME
open, openat - open a file
DESCRIPTION
～省略～
The open() function returns a file descriptor for the named
file that is the lowest file descriptor not currently open
for that process. The open file description is new, and
therefore the file descriptor does not share it with any
other process in the system. The FD_CLOEXEC file descriptor
flag associated with the new file descriptor is cleared.
～省略～
と書いてあります。
MAEDA Atusi
> In article <b162s4$2dvm$1...@maha2.doga.co.jp>, Masamichi Takatsu <ta...@doga.jp> writes
> >open が未使用の中で最小の記述子を返すなどとは規定されていなかったかと。
>
> うーん、そんなことされると結構動かなくなるプログラムがあるん
> じゃないかと... でも、この方法を読んだのは OS-9 (Macじゃない
> 奴)のマニュアルだからなぁ。
SUSv3 (ISO/IEC 9945:2002, IEEE Std 1003.1-2001)には、
The open() function shall return a file descriptor for the named file
that is the lowest file descriptor not currently open for that
process.
とあります。
でも、fopen()はまた別の話ですよね。
> 動かないものの方が多いってことなのかな。といいつつ、BSD, Sun
> OS, Solaris, BSD/OS と BSD系列でしか動かしてなかったんだけど。
> Mac OS X でも、
> #define stdin (&__sF[0])
> なんです。
＃ SolarisはBSDなの?? あ、Solaris1.xのこと?
> これだと、fclose/fopen で切替えられます。おそらく、
> それを意識した実装なんだと思う。
ってのはなんかダウトだなあ。そんなことする意味が分からない。
FILE *out = stdout;
...
if (redirect) out = fopen(...);
で良いじゃないですか。
> でも、
> extern FILE *stdout;
> ってのは、ちょっと新鮮でした。Linux でも前は動いていたような
> 気もするんだけど、錯覚だったんだろうな。
Linuxでも大昔は
#define stdin (&_iob[0])
とかだったような。
まあLinuxのlibcは(是非はともかく)移植性について面白い点が昔から色々あ
りますよね。mallocしてないものをfreeに渡すと落ちたりとか、isspaceとか
に負の値を渡してもOKとか...「BSD(本物)で動いたんだから、動かない処理系
の方がニセモノ」と言えた良き(?)時代とは変わったと言うか...
> もちろん実装によるん
> だけど、FILE構造体をいちいちmalloc/free するのが良い実装とも
> 思えない。どうせ一段indirectが入るかどうかでしかないんだけど、
> getchar() とかの最適化には影響するんじゃないかなぁ。
stdinだけgetcが速いとか?
＃ でも、mallocっていつやるんでしょうね。stdio.hをインクルードしないと
＃ されないんでしょ? C++みたいにextern変数の初期化に関数呼び出しが使え
＃ る?
前田敦司
Shinji KONO
In article <m31y2wk...@maedapc.cc.tsukuba.ac.jp>, MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes
>＃ SolarisはBSDなの?? あ、Solaris1.xのこと?
2.6ですけど、
#define stdout (&_iob[1])
ですね。
>> これだと、fclose/fopen で切替えられます。おそらく、
>> それを意識した実装なんだと思う。
>ってのはなんかダウトだなあ。そんなことする意味が分からない。
そうかなぁ。open/fopen で同じような性質を持つのは重要だと思う。
いままで、ずーっと動いてたのに。
>FILE *out = stdout;
>...
>if (redirect) out = fopen(...);
>で良いじゃないですか。
それじゃ、printf がリダイレクトできないじゃん。
>stdinだけgetcが速いとか?
うんうん。そんな感じ。でもsetbufとかどうせあるしな。
>まあLinuxのlibcは(是非はともかく)移植性について面白い点が昔から色々あ
>りますよね。mallocしてないものをfreeに渡すと落ちたりとか、isspaceとか
>に負の値を渡してもOKとか...「BSD(本物)で動いたんだから、動かない処理系
>の方がニセモノ」と言えた良き(?)時代とは変わったと言うか...
つうか、変えるなよ～ stdout に代入できるかどうかって結構差が
あると思うんだけど。
「mallocしてないものをfreeに渡すと落ちたり」これは防ぐのは結
構難しい。free でmalloc list をsearchするのを許してもらえる
と防げるけど、結構、重いんじゃないかな。
Masamichi Takatsu
なんか、似たようなことを昔書いた覚えがあると思ったのですが、
fj.net.programming の
<t88zi4y...@moonstone.inet.mmp.fujitsu.co.jp>
あたりでやってました。
<9i7i9h$5hd$1...@maha2.doga.co.jp>
で書いてますけど、FreeBSD のmanには最小を返すなどとは書かれてません。
今の FreeBSD-4.7 も同じ。
Linux の方は、当時調べた Laser5 Linux には書いてなかったのですが、
今 RedHat 7.3 のを見たら、最小のを返すとなってます。
記事 <m31y2wk...@maedapc.cc.tsukuba.ac.jp> で
MAEDA Atusiさんは書きました
> SUSv3 (ISO/IEC 9945:2002, IEEE Std 1003.1-2001)には、
> The open() function shall return a file descriptor for the named file
> that is the lowest file descriptor not currently open for that
> process.
> とあります。
なるほど。POSIX では最小を返すのですね。とすると、FreeBSDのopenがPOSIXに
準拠していないってことでしょうか? (たぶん、単にmanに書かれてないだけで、
実質はちゃんと最小を返してるんでしょうけど…)
PROJECT TEAM ＤｏＧＡ 高津正道 ta...@doga.jp
TBD0...@nifty.ne.jp
PROJECT TEAM DoGAのホームページ → http://doga.jp/
1月29日(水) 今日のマーフィーの法則 [マーフィーの法則の第7番目の発展形]
全ての解決は、新たな問題を産む。
MAEDA Atusi
> >> これだと、fclose/fopen で切替えられます。おそらく、
> >> それを意識した実装なんだと思う。
> >ってのはなんかダウトだなあ。そんなことする意味が分からない。
>
> そうかなぁ。open/fopen で同じような性質を持つのは重要だと思う。
> いままで、ずーっと動いてたのに。
そりゃあCとUnixがもれなくセットだった1970年代の発想では。
今のCの世界で言えばopenなんて知ったこっちゃないでしょう。
> >FILE *out = stdout;
> >...
> >if (redirect) out = fopen(...);
> >で良いじゃないですか。
>
> それじゃ、printf がリダイレクトできないじゃん。
・最初から全部 fprintf(out, ...) で書いておく。
・printfを直接使わず、リダイレクトの効くprintoutとかを呼ぶ。
・#define printf(__VA_ARGS__) fprintf(out, __VA_ARGS__)...は反則か。
・素直にfreopenを使う。
とか、『いかにも処理系依存』のトリックを使わなくても、ましな方法はいく
らでもあるように思うんですが。
> つうか、変えるなよ～ stdout に代入できるかどうかって結構差が
> あると思うんだけど。
いかにも変数みたいな外見なのに代入できないってのは汚らしいですよね。
(stdin, stdout, stderrが小文字でFILEが大文字という、現在のCの慣習にま
るきり反した名前は、まさに「先史時代の名残り」という感じがしますね。)
> 「mallocしてないものをfreeに渡すと落ちたり」これは防ぐのは結
> 構難しい。free でmalloc list をsearchするのを許してもらえる
> と防げるけど、結構、重いんじゃないかな。
mallocのふるまいがこういうふうに(staticへのポインタとかをfreeに渡すと
落ちるように)変わった時、「他のOSで動いているプログラムが動かない」と
いう苦情が続出しました。Solarisとかだと平気で動いてたんですね。FreeBSD
では実行時に警告が出たような記憶が。もちろん、どの振舞いでも良い(規格
準拠ではある)んですが、まあ個人的には黙って動いちゃうのは不親切かなと。
前田敦司
Kazuo Fox Dohzono
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> でも、
> extern FILE *stdout;
> ってのは、ちょっと新鮮でした。
Linux のこれって規格に沿ってないって話ありませんでしたっけ. 規格では
stdout はマクロということになってる.
| [#1] The header <stdio.h> declares three types, several
| macros, and many functions for performing input and output.
| [#2]
…
| stderr
| stdin
| stdout
|
| which are expressions of type ``pointer to FILE'' that point
| to the FILE objects associated, respectively, with the
| standard error, input, and output streams.
extern FILE *_stdout;
#define stdout _stdout
だと ok とか :-)
KOYANAGI Masaaki
At 29 Jan 2003 01:15:30 GMT,
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
>
> 久野です。
>
> ta...@doga.jpさん:
> > そもそも、これも保証されないんじゃないですか? open が未使用の
> > 中で最小の記述子を返すなどとは規定されていなかったかと。
>
> どこで、ですかね。Solaris 2.6のmanページではそれが保証されると
> 書いてあります。
Solaris 8 でも man open すると
>The open() function returns a file descriptor for the named
> file that is the lowest file descriptor not currently open
> for that process.
と書いてあります。
HP-UX 11.0 と Linux 2.4 では書いてありませんでした。
--
小柳 雅明(http://homepage1.nifty.com/dreaming/)
「人の足を止めるのは"絶望"ではなく"諦観"
人の足を進めるのは"希望"ではなく"意志"」
-- ARMS
MAEDA Atusi
> Linux のこれって規格に沿ってないって話ありませんでしたっけ. 規格では
> stdout はマクロということになってる.
> extern FILE *_stdout;
> #define stdout _stdout
>
> だと ok とか :-)
こうなってますね。
/* Standard streams. */
extern FILE *stdin; /* Standard input stream. */
extern FILE *stdout; /* Standard output stream. */
extern FILE *stderr; /* Standard error output stream. */
#ifdef __STDC__
/* C89/C99 say they're macros. Make them happy. */
#define stdin stdin
#define stdout stdout
#define stderr stderr
#endif
前田敦司
Takashi SHIRAI
In article <m31y2wk...@maedapc.cc.tsukuba.ac.jp>,
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> wrote:
>＃ SolarisはBSDなの?? あ、Solaris1.xのこと?
2 以降も系譜から言うと BSD のなれの果てなので、SVR4 陣営に
しては実装の節々に BSD 系の名残が見られますよね。
POSIX では表層的な仕様しか定められていないので、こういう実
装を云々する場合は、Solaris は SVR4 としてではなくて BSD と
して見なした方が適切かも知れません。
>> extern FILE *stdout;
>> ってのは、ちょっと新鮮でした。Linux でも前は動いていたような
>> 気もするんだけど、錯覚だったんだろうな。
「static FILE *fp = stdout;」みたいなのも駄目なので、この
辺りの実装の差異は厄介ですね。GNU/Linux is Not Unix なんで仕
方ないんでしょうけど。
>まあLinuxのlibcは(是非はともかく)移植性について面白い点が昔から色々あ
>りますよね。mallocしてないものをfreeに渡すと落ちたりとか、isspaceとか
>に負の値を渡してもOKとか...「BSD(本物)で動いたんだから、動かない処理系
>の方がニセモノ」と言えた良き(?)時代とは変わったと言うか...
Linux の free() は良く落ちますねー。free() したのをも一度
free() しても落ちます。それも関係ないところで、例えば次に実
行した malloc() の時とか、別の malloc() で得た領域を access
した時とか、一見謎の落ち方をするので debug が大変。
ところで、負数は負数でも isspace(-1) は昔でも OK な実装が
多かったんじゃないでしょうか？EOF が通らないといけないんで。
>＃ でも、mallocっていつやるんでしょうね。stdio.hをインクルードしないと
>＃ されないんでしょ? C++みたいにextern変数の初期化に関数呼び出しが使え
>＃ る?
Linux の malloc() を trace して結構追いかけ回したことがあ
るんですが、stdin/out/err の確保用には malloc() は呼ばれてい
ないようですよ。printf() したくらいじゃあ malloc() の log に
は残りませんから。
そもそも最初の fopen() で初めて stream 関数用の buffer が
malloc() されるので、stdin/out/err 用には何かまた別の stream
領域が割り当てられているんじゃないでしょうか。
--
しらい たかし
MAEDA Atusi
> >> extern FILE *stdout;
> >> ってのは、ちょっと新鮮でした。Linux でも前は動いていたような
> >> 気もするんだけど、錯覚だったんだろうな。
>
> 「static FILE *fp = stdout;」みたいなのも駄目なので、この
> 辺りの実装の差異は厄介ですね。GNU/Linux is Not Unix なんで仕
> 方ないんでしょうけど。
いや、まあ、他の多くのマクロが「constant expressionに展開される」と書
いてあるのに対してstd{in,out,err}は単に「expressionに展開される」とあ
りますから、C99的にはconstantであることを期待しちゃいかんのでしょう。
Unix的には確かに鬼っ子ですね... と書こうと思ったら、SUSv3の「stdin」の
項を見ると:
SYNOPSIS
#include <stdio.h>
extern FILE *stderr, *stdin, *stdout;
と書いてありますから、今はこれが正しいんですね。
(ちなみに、
The Single UNIX Specification Version 3
= IEEE Std 1003.1-2001
= ISO/IEC 9945:2002
は、http://www.unix.org/version3/online.html で登録すれば無料で見られ
ます。)
> Linux の free() は良く落ちますねー。free() したのをも一度
> free() しても落ちます。それも関係ないところで、例えば次に実
> 行した malloc() の時とか、別の malloc() で得た領域を access
> した時とか、一見謎の落ち方をするので debug が大変。
これは環境変数MALLOC_CHECK_を1にセットしてやると検出できますね。
まあ、チェックで遅くなるのが嫌だという処理系作成者の気持ちは分からんで
もないです。
> ところで、負数は負数でも isspace(-1) は昔でも OK な実装が
> 多かったんじゃないでしょうか？EOF が通らないといけないんで。
御意です。
これはたしか渡邊さんにfj.comp.lang.cで教わった話だと思うんだけど、
(mallocとは逆に)Linuxで動くのに他のUnixで動かないプログラムが続出して、
原因は8bit目が立った文字(getchar()とかの値だと128～255, charに格納する
と-128～-1)をctype.hの各関数に渡してもLinuxでは平然と動くからだったと
か。
＃ あれ、-1は... isxxx()ではたいてい0を返せば良いのかな。
> Linux の malloc() を trace して結構追いかけ回したことがあ
> るんですが、stdin/out/err の確保用には malloc() は呼ばれてい
> ないようですよ。printf() したくらいじゃあ malloc() の log に
> は残りませんから。
なるほど。じゃあ「printf()でmalloc()が勝手に呼ばれちゃう」というのは杞
憂ですか。
前田敦司
KATAYAMA Yoshio
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
>いや、まあ、他の多くのマクロが「constant expressionに展開される」と書
>いてあるのに対してstd{in,out,err}は単に「expressionに展開される」とあ
>りますから、C99的にはconstantであることを期待しちゃいかんのでしょう。
C90 もそうですね。
>Unix的には確かに鬼っ子ですね... と書こうと思ったら、SUSv3の「stdin」の
>項を見ると:
>SYNOPSIS
>#include <stdio.h>
>extern FILE *stderr, *stdin, *stdout;
>と書いてありますから、今はこれが正しいんですね。
FreeBSD 3.4 では、
SYNOPSIS
#include <stdio.h>
FILE *stdin;
FILE *stdout;
FILE *stderr;
となっていますが、stdin などは constant expression になっていま
す。“SYNOPSIS”なんですから、C の規格に書いてないこと（lvalue
であるとか）まで期待しない方がいいんじゃないでしょうか。
>> Linux の malloc() を trace して結構追いかけ回したことがあ
>> るんですが、stdin/out/err の確保用には malloc() は呼ばれてい
>> ないようですよ。printf() したくらいじゃあ malloc() の log に
>> は残りませんから。
そこまでしなくても、
#include <stdlib.h>
#include <stdio.h>
int
main(void)
{
static int i;
void *p = malloc(1);
extern char etext[], edata[], end[];
printf("etext = %.8p, edata = %.8p, end = %.8p\n", etext, edata, end);
printf("stdout = %.8p, i = %.8p, p = %.8p\n", stdout, &i, p);
}
で充分な気がしますけど。
＃ extext とかが man から消えてる、、、＞ Linux
>なるほど。じゃあ「printf()でmalloc()が勝手に呼ばれちゃう」というのは杞
>憂ですか。
ですね。
--
片山＠ＰＦＵ
Kazuo Fox Dohzono
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> #ifdef __STDC__
> /* C89/C99 say they're macros. Make them happy. */
> #define stdin stdin
> #define stdout stdout
> #define stderr stderr
> #endif
「gcc -traditional だとループするやん!」とか思ったけど, この場合
__STDC__ が定義されないんですね.
# 昔は無かったと思ったけど自信無し.
Kusakabe Youichi
<ma...@cc.tsukuba.ac.jp> wrote:
> > 「mallocしてないものをfreeに渡すと落ちたり」これは防ぐのは結
> > 構難しい。>
> 落ちるように)変わった時、「他のOSで動いているプログラムが動かない」と
> いう苦情が続出しました。
fclose(NULL)になってしまうコードが、
VAX/BSDで動いてて、MS-DOSでも動いてて、
NCRのTowerでcore dumpするまで気づかなかったこともあります。
--
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾