Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.

[Russ Allbery <eagle at eyrie dot org>]

Rich Felker <dalias@aerifal.cx> 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:

> http://austingroupbugs.net/view.php?id=529

> 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 (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>