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 14:52:00 -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> <87ob4vggn3 dot fsf at windlord dot stanford dot edu> <20131205223223 dot GQ24286 at brightrain dot aerifal dot cx>
Rich Felker <firstname.lastname@example.org> writes:
> You missed the beginning of this discussion (which, to be fair, was in
> another thread:
> https://www.sourceware.org/ml/libc-alpha/2013-12/msg00108.html) where it
> was noted that POSIX has fixed this bug:
> The new requirement is that EINTR means the fd is still open and
> EINPROGRESS means the operation was interrupted by a signal but the fd
> is no longer valid.
Ah, thank you, I did.
However, that does imply that all C programmers should, to avoid file
descriptor leaks on conforming POSIX systems, check the return status of
close() and retry (some number of times?) if close fails with EINTR.
I'm pretty sure that almost no one does that in real code.
I think it might be best to view this issue in a similar light to the old
C question of whether you can safely initialize structures containing
pointers with memset of 0 and then rely on the pointers being NULL. In
theory, you can't, because NULL on an arbitrary C platform might not be
all-zero bits; in practice, nearly all code does this and systems that
don't use an all-zero bit value for NULL will not be able to safely run
the vast majority of existing C code. So everyone just assumes this works
and goes on with their lives.
I suppose what I'm saying is that I'm in agreement with you that returning
0 is probably the best approach, since it's not at all clear what we gain
from returning -1 with EINPROGRESS and I doubt code deals with it
correctly anyway. (It's not even clear to me what "correctly" would
entail in that case.) That said, between the other choices, the
EINPROGRESS approach which declares the file descriptor closed strikes me
as clearly better than the POSIX EINTR semantics (which sound like they're
not even possible on Linux).
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>