Re: [PATCH] git-rev-list: give better diagnostic for failed write
- From
Jim Meyering <jim@meyering.net>
- Date
- Jun 27, 2007, 08:56 UTC
- Message-ID
- <87wsxppygx.fsf@rho.meyering.net>
- In-Reply-To
- <alpine.LFD.0.98.0706251557090.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote: ...
Show 7 quoted lines
> So I didn't mean to imply that the new git.c code in 'next' is wrong, I > just meant to imply that the "ferror()"+"fflush()" sequence that it uses > and that I copied for my example is a very unreliable sequence, and it > basically fails exactly because you can never know what caused the > ferror() to trigger - if it *ever* triggers, you're basically screwed. > > I wonder how many applications actually ever use ferror() and friends.
At least among GNU programs, many do. Here are a few:
gcc, make, diff, grep, tar, find, xargs, gawk
And add to that 89 or 90 of the coreutils programs:
$ git-grep -l close_stdout|grep 'src/.*\.c'|wc -l
89But none of those suppress EPIPE errors, so ferror works fine for them. That's partly because the ferror-only situation is far less common than the one in which we have a valid errno value.