Date: Fri, 29 Dec 2017 11:27:21 -0700 From: Ian Lepore <ian@freebsd.org> To: Yuri <yuri@rawbw.com>, Freebsd hackers list <freebsd-hackers@FreeBSD.org> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <1514572041.12000.7.camel@freebsd.org> In-Reply-To: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2017-12-29 at 10:19 -0800, Yuri wrote: > Some base utilities sometimes close files that they open for their > purposes without checking the error code of close(2). > > Is this considered to be ok, because it's just a close call and we > are > done with that file descriptor, or is it considered to be more > appropriate to check close's error code? > > Maybe there is some policy that covers this? > > IMO, every system call's return value should be checked, just in > case. > > > Yuri > There's really no point in checking on a close from a file opened only for reading. You can argue it should be checked on a file open for writing, but often isn't because you're then confronted with the question "what should/can I do if there is an error?" If you report the error and exit, then what about other files that were open at the time? They're going to be closed by the kernel as part of process cleanup, with no error checking or reporting. Also, with the async nature of filesystems, IO errors can still happen after the close, unless fsync() was used. So if you're going to miss most of the errors because of that, why bother to check at all? -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1514572041.12000.7.camel>