This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 <>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]