Re: rationale for closein

[Bruno Haible]

Rich Felker wrote about 'closeout':
> ... Conceptually, you're
> turning something that's a local variable  ... into a global, and
> thereby losing the _local_
> information of whether it was used in the first place, which has to be
> recovered with the non-portable __fpending.

Correct. We do this because it would be too tedious to keep track,
in local variables outside of the stream, whether it was "used in the
first place".

> the same code that checks for write errors and reports failure
> for explicitly-opened files would also check and report write errors
> on stdout.

The code has been generalized: There are two (quite similar) modules
'close-stream' and 'fwriteerror'.

> > 'closein' is similar - an attempt to fix an issue that affects many 
> > programs,
> > once and for all. By Eric Blake.
> 
> I think closein is just a no-op for conformant implementations. exit
> implicitly closes all streams, including stdin, and per POSIX, fclose
> has the following effect:
> 
>     If the file is not already at EOF, and the file is one capable of
>     seeking, the file offset of the underlying open file description
>     shall be adjusted so that the next operation on the open file
>     description deals with the byte after the last one read from or
>     written to the stream being closed.
> 
> As such, close_stdin's attempt to fix-up the file position seems to be
> redundant.
> 
> Incidentally, I suspect musl is _not_ currently handling this case
> correctly.

And glibc is not handling it correctly either:
<http://sourceware.org/bugzilla/show_bug.cgi?id=12724>
Which is why 'closein' is needed in gnulib.

> Does gnulib have some tests that assert the required
> behavior, which I could use to test the current behavior and any
> efforts to fix it if it's wrong?

Not in gnulib. But you find two test programs attached in the bug report
from Eric, cited above.

Bruno