Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
...
> 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
89
But 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
