[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Jul 2011 21:49:03 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: close(2) failure cases (was: some fixes to musl)
Rich,
On Sun, Jul 24, 2011 at 08:24 -0400, Rich Felker wrote:
> > Even if close() fails, the fd is freed. So fd leakage is impossible.
>
> Is this true even in the case of EINTR?
For all types of fd the fd is deleted from fd table, then
FS-specific function is called. Any error would be returned to the
program, but fd would be already deregistered.
I agree with POSIX in part that close() should somehow signal about
failed IO (e.g. no free disk space) and error return code is good
enough. However, I feel it was wrong to leave undefined behaviour of fd in
case of error. If the file is so important that the error must be
handled by the program, it really should do *sync() and react on its
error. IMO close() should unconditionally close fd. (The same for
fclose(3), etc.)
Thanks,
--
Vasiliy
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.
