Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Jul 2011 08:24:02 -0400
From: Rich Felker <>
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...)


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.