This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.
- From: Russ Allbery <eagle at eyrie dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 05 Dec 2013 12:57:36 -0800
- Subject: Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.
- Authentication-results: sourceware.org; auth=none
- References: <20131205175749 dot GL24286 at brightrain dot aerifal dot cx> <20131205195802 dot GA19289 at lst dot de> <20131205201126 dot GO24286 at brightrain dot aerifal dot cx> <20131205 dot 155009 dot 707968344039994800 dot davem at davemloft dot net>
David Miller <firstname.lastname@example.org> writes:
> At one time many years ago there was a path in the kernel that returned
> an error from close and it broke so many things. Even emacs crashed.
> The widespread overwhelming belief is that close() is just going to
> always succeed, and there is more harm than good from signalling errors
> at all from that function.
Indeed, all the C code that I've seen either assumes that failure on
close() is some sort of write failure and treats it as such, or ignores
failure entirely. Having close() return a failure and leave the file
descriptor open would cause a file descriptor leak in most code I've seen
and would result in a possibly incorrect diagnosed failure to write to the
file in all of the rest.
It's very unclear what a C programmer should do when close() returns
failure. POSIX 2008 says that the state of the file descriptor after a
close failure is undefined, which I assume means that one should just
retry the close (how many times?), but that relies on the assumption that
it's safe to close a file descriptor that's already closed and the worst
that will happen is that you'll get back EBADF.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>