[RFC] Shall we loop on EINTR for fclose too?

[Carlo Wood]

On Sat, Aug 28, 2004 at 02:07:15AM +0200, Paolo Carlini wrote:
> Hi,
> 
> PR libstdc++/17215 seems rather simple: in filebuf we are missing a check on
> the return value of fclose and filebuf::close() doesn't return a null 
> pointer
> when the underlying fclose fails: we add the check and we are mostly done...
> 
> However, there is a special case: what if fclose sets errno = EINTR? The C
> standard doesn't mention this possibility (Posix does) and the C++ standard
> only says: call fclose.
> 
> It seems to me that the best solution is at the abstraction level of our
> __basic_file<>::close: we should *loop* on EINTR there, exactly as we are
> already doing for read and write.
> 
> We return error (a null pointer) to the caller (filebuf::close()) only in
> case of real error. Before returning, in any case (real error or success) we
> shall zero _M_cfile (the FILE*).
> 
> Thanks for any feedback!
> Paolo.

This is code from my current project:

    while ((failure = (::close(M_fd) == -1)) && errno == EINTR);

I guess that I agree thus ;).  Note that if fclose() returns EINTR then
that can mean that a final write(2) to flush the buffers was interrupted.
Obviously we don't want to "close" a file without doing this last flush
correctly.  I therefore think that the EINTR must be treated exactly as
the one for write, like you said.

-- 
Carlo Wood <carlo@alinoe.com>