[Bug-gnulib] closeout doesn't always close: which is better: always or never?

[Jim Meyering]

I noticed that closeout.c's close_stdout doesn't close stdout when
that stream's error bit is clear and there is nothing to flush.
It seems wrong (given the name) not to close.  So the question is:

  Which is better: to close all of the time, or never?

If never closing is better, then it'd be better to use names like
flush_stdout and flush_stdout_set_file_name for those functions,
and maybe even to rename the files.  That's pretty invasive,
but I'd happily do it for coreutils.  FWIW, with such a change in
functionality (fflush rather than fclose) the coreutils test suite
still passes.  That's not surprising, since in coreutils applications,
close_stdout is called exclusively via atexit.

Would such a change in functionality affect any other package that
uses closeout.c?

Never closing seems slightly cleaner, but if there's a way in which
a subsequent close can fail, then always closing would be better.
Taking the other side, maybe it's better always to close, just
to be sure that if post-close_stdout code attempts further output
it'll fail.

What do you think?