cmp: Check the status of stdout.

[des]

Summary

POSIX requires us to print an error message and exit non-zero if
writing to stdout fails. This can only happen if sflag is unset.

MFC after: 3 days
Sponsored by: Klara, Inc.

[markj]

There are two many separate exit points, so install an atexit handler before calling anything that may print to stdout.

But almost all of them are exiting with a non-zero status. Don't you just need to handle those that exit with status 0?

[kevans]

In D47020#1071814, @markj wrote:

There are two many separate exit points, so install an atexit handler before calling anything that may print to stdout.

But almost all of them are exiting with a non-zero status. Don't you just need to handle those that exit with status 0?

Strictly speaking, yes- other errors should take precedence over a flush error, even if we could have encountered the flush error first but didn't bother error checking all of the writes to stdout.

[des]

DIFF_EXIT is non-zero but not an error. Unless -s was specified, it is preceded by a message to stdout, and POSIX requires us to not only exit non-zero but also print an error message to stderr if writing to stdout fails. I suppose this would be clearer if I rewrote cmp to return non-error results back to main so there was only a single non-error exit point, and then try to fflush(stdout) iff !sflag, rather than use atexit().

[des]

avoid atexit

[des]

more thorough testing

[markj]

Thank you, I think this is nicer.

[markj]

usr.bin/cmp/tests/cmp_test2.sh

144

If I run this test case in a loop with some load in the background, e.g., from a build, there is an occasional failure because the result is 1 instead of 2.

I wonder if the test is racy because the subshell is able to write to the pipe buffer before the other end exits, triggering EPIPE?