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
