rationale for closein

[Bruno Haible]

Rich Felker wrote in
<http://www.openwall.com/lists/musl/2012/06/18/8>:
> I've already discussed on this list why using an atexit function for
> closing stdin or stdout is the heart of the problem and the source of
> all the complexity. If the main program just closed the stream at the
> natural point in the normal program flow, it would be trivial to do
> correctly and portably.

Here's how this 'closein' module came about:

Jim, maintainer of coreutils (a set of ca. 100 programs), noticed that
the programs failed to report an error when writing to a full disk. Not only
  $ cat file1 file2 > /full-partition/output
but also
  $ id -u > /full-partition/output
or
  $ sort --help > /full-partition/output

The problem is that not only the "normal program flow" needs to be
considered, but all program flows from the start of main() to exit().
He could have changed the source code of all 100 programs so that this
bug would be fixed, but that would not give a guarantee that the bug would
not be reintroduced as new code branches are added in existing programs,
or as new programs are being written. So he searched for a solution that
would prevent the bug from reappearing and also not increase the maintenance
burden, and came up with 'closeout'.

Jim made a presentation about this:
http://www.gnu.org/ghm/2011/paris/#sec-2-1
http://www.irill.org/events/ghm-gnu-hackers-meeting/videos/jim-meyering-goodbye-world-the-perils-of-relying-on-output-streams-in-c

'closein' is similar - an attempt to fix an issue that affects many programs,
once and for all. By Eric Blake.

Bruno