[Bug libstdc++/17215] __basic_file<char>::close ignores errors

[ken at xorian dot net]

------- Additional Comments From ken at xorian dot net  2004-08-27 22:49 -------
> I doubt it. Again, see 7.19.5.1: the semantics of fclose in the C
> standard is not the same of close (in Posix, or what else):
> 7.19.5.1, p2, clearly points out that even when fclose fails there
> are no risks of leaks, since the buffers are deallocated
> anyway. Also, the stream is disassociated from the file and you
> cannot perform additional operations on it. All of this implies, in
> my opinion, that your fix should be tweaked to do _M_cfile = 0
> unconditionally.

I admit I had not checked C99 on this, and I find what you point out
to be rather distressing actually.  Several other references (the
Single UNIX Specification, man pages on Linux and Tru64) say that
fclose can fail with errno=EINTR.  I had assumed that in the event of
that kind of temporary failure (where the normal thing to do is to
repeat the operation) that one would be able to call fclose on the
same stream to complete the write(2) or close(2) that had been
interrupted.

If a C run-time library were to implement fclose as C99 seems to
describe, then such a transient error would be totally unrecoverable.
That would make stdio and by extension std::fstream unusable for any
application that required data integrity.

It may be worth mentioning that I noticed the problem this bug report
is about because I had fstream::open fail with errno=EINTR.  I've been
trying to identify all the changes I need to make to at the
application level to properly protect against this causing spurious
failures.  Since fstream::open can fail in this way, it seemed
sensible to add the same protection and repeating of the operation on
EINTR around fstream::close.  (I did check the C++ spec, which states
that basic_filebuf::close will fail is fclose fails.)

> By the way, is your patch already regression tested? Can you think
> of any testcases?

I did not run any of the regression tests included with gcc on it,
though I've done some very minimal testing using it with some code I'm
working with.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17215