アカウント名:
パスワード:
・C言語の高水準入出力 printf(3) とか fputs(3) で出力した内容はキャッシュされるので fclose(3) とか fflush(3) とかで吐き出して戻り値を確認しないと正常に出力されたことは保証されない。・exit(3) なり main() からの return で暗黙にフラッシュした場合はエラーチェックできないので、失敗してもわからない。
というのは基本仕様なので知っとく必要がある。/dev/full とかだけでなく、write(2)で発生するあらゆるエラーの可能性がある。
これC言語にフォーカスしているからおかしい(のとC言語もバグ扱いにしているのがおかしい)。JavaとかNode.jsみたいに例外処理がある処理系でも発生しているのは確かに不思議。Javaは調べてみると、PrintStreamはIOExceptionを投げない [oracle.com]となっているから、そもそもそういう仕様なのね。# バグを仕様と言い張るのと逆で、仕様をバグと言い張っているのか
Javaでもmainメソッドの外で暗黙に閉じられたstreamが仮に例外を投げるとしてもcatchのしようがないのでは?
Javaも例外が拾われずに終了する場合は1(エラー)を返すので、問題はキャッシュしたstreamがflushされるタイミングですね。普通に考えて処理最後にはflushされるはずなので、仮にstreamが例外をthrowするならエラーで終わる気がします。C#はエラーになっているので、そのあたりは作りしだいですが。
c# (net6)は挙動とソースをみると、Console.Writen系では毎回呼び出し毎にflushしているので、呼んだ時点で例外が起きる。CはターミナルならLine Bufferingだが、リダイレクトされているとFull Bufferingになるのでfwriteした時点では気づかないとかの話になる。まあこれもパフォーマンスの話で気になるならsetlinebufなりsetvbuf(_IONBF)なり呼べば、というのもわかる話。API設計の時代背景(かWindows文化的にリダイレクトをバッファリングするとデメリットがでるのでやらない)だろうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
/dev/full 関係ないじゃん。 (スコア:5, すばらしい洞察)
・C言語の高水準入出力 printf(3) とか fputs(3) で出力した内容はキャッシュされるので fclose(3) とか fflush(3) とかで吐き出して戻り値を確認しないと正常に出力されたことは保証されない。
・exit(3) なり main() からの return で暗黙にフラッシュした場合はエラーチェックできないので、失敗してもわからない。
というのは基本仕様なので知っとく必要がある。
/dev/full とかだけでなく、write(2)で発生するあらゆるエラーの可能性がある。
Re: (スコア:0)
これC言語にフォーカスしているからおかしい(のとC言語もバグ扱いにしているのがおかしい)。
JavaとかNode.jsみたいに例外処理がある処理系でも発生しているのは確かに不思議。
Javaは調べてみると、PrintStreamはIOExceptionを投げない [oracle.com]となっているから、そもそもそういう仕様なのね。
# バグを仕様と言い張るのと逆で、仕様をバグと言い張っているのか
Re: (スコア:0)
Javaでもmainメソッドの外で暗黙に閉じられたstreamが仮に例外を投げるとしてもcatchのしようがないのでは?
Re: (スコア:0)
Javaも例外が拾われずに終了する場合は1(エラー)を返すので、問題はキャッシュしたstreamがflushされるタイミングですね。
普通に考えて処理最後にはflushされるはずなので、仮にstreamが例外をthrowするならエラーで終わる気がします。
C#はエラーになっているので、そのあたりは作りしだいですが。
Re:/dev/full 関係ないじゃん。 (スコア:3)
c# (net6)は挙動とソースをみると、Console.Writen系では毎回呼び出し毎にflushしているので、呼んだ時点で例外が起きる。
CはターミナルならLine Bufferingだが、リダイレクトされているとFull Bufferingになるのでfwriteした時点では気づかないとかの話になる。まあこれもパフォーマンスの話で気になるならsetlinebufなりsetvbuf(_IONBF)なり呼べば、というのもわかる話。
API設計の時代背景(かWindows文化的にリダイレクトをバッファリングするとデメリットがでるのでやらない)だろうね。