[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110724122402.GH132@brightrain.aerifal.cx>
Date: Sun, 24 Jul 2011 08:24:02 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: close(2) failure cases (was: some fixes to musl)
On Sun, Jul 24, 2011 at 01:19:18PM +0400, Vasiliy Kulikov wrote:
> I've looked at some Linux code related to close(). It may fail iff
> file_ops->flush() is not NULL, and close() fails iff ->flush() fails.
Thank you for making the effort to investigate!
> Even if close() fails, the fd is freed. So fd leakage is impossible.
Is this true even in the case of EINTR?
> As musl is Linux specific libc, you're free to rely on Linux specific
> restrictions/features. However, I don't know whether close()
> implementation is guaranteed to be errorless for these types of files.
> If no, it may be changed in the future by introducing some new feature
> (and it will not break POSIX as POSIX explicitly defines close()
> failure possibility). It's very unlikely though, as breaking tons of
> programs relying on implicit Linux behaviour is not encouraged by Linus.
Not only does it break lots of programs; it also makes fixing those
programs impossible. There is simply no way to recovery from failed
resource deallocation. (Think of C++ and RAII...)
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
