This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] Shall we loop on EINTR for fclose too?
- From: Carlo Wood <carlo at alinoe dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, Nathan Myers <ncm at cantrip dot org>, ken at xorian dot net
- Date: Sat, 28 Aug 2004 11:21:51 +0200
- Subject: Re: [RFC] Shall we loop on EINTR for fclose too?
- References: <412FCCB3.9040601@suse.de>
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>