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.