Date: Sat, 30 Dec 2017 09:20:47 -0800 From: Larry McVoy <lm@mcvoy.com> To: Ian Lepore <ian@freebsd.org> Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, Eugene Grosbein <eugen@grosbein.net>, 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: <20171230172047.GK22177@mcvoy.com> In-Reply-To: <1514654174.12000.15.camel@freebsd.org> References: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> <1514654174.12000.15.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 30, 2017 at 10:16:14AM -0700, Ian Lepore wrote: > On Sat, 2017-12-30 at 07:44 -0800, Rodney W. Grimes wrote: > > [ Charset windows-1252 unsupported, converting... ] > > > > > > > > 30.12.2017 21:06, Rodney W. Grimes wrote: > > > > > > > > > > > > > > > > > Of course, there are cases when that's irrelevant, f.e. closing temporary file > > > > > that is no more needed and being unlinked anyway. > > > > No error on close should be treated as irreleveant, they signify something > > > > has gone wrong and itis best to inform the user and let the user decide > > > > if this is irrelevant or not. > > > > > > > > Code that does not test return codes from EVERY single thing that can > > > > return an error should be taken out back shown the danish axe, clean it > > > > up or get it out of our tree! > > > An application checks for error code after writing to stderr to report an error > > > and finds it failed too; and what should be done then? :-) > > One should do the right thing, you know that this is a case of the > > output to stderr failed, and that it would not be right to try to > > output another error, but probably just call exit with a non zero > > value so that the caller may be able to do something with that > > data. > > > > Your trying to over complicate what is a very simple rule, if a status > > can be returned, one should check it and try to do the best thing possible. > > Or maybe we should just turn off the compiler warning that flags this? > > No, you're trying to impose a ridiculously simple rule onto what is > inherently a complex situation. ?The idea that every close() should be > checked is just ludicrous. ?What about output to stdout? ?Does a > program under your rules explicitly need to close() stdout and check > the return code? ?If not, justify how a failure to write to stdout in a > typical unix pipeline-oriented tool is less important than writes > directly to a disk file. ?How about stderr? ?If that fails, what do you > do? > > Even the earlier simplistic notion that all close() calls should be > asserted still overlooks the fact that virtually every application has > multiple files open, and if an assert triggers on one close(), none of > the other closes (perhaps equally or more important ones) will ever get > checked or reported. ?Writing code into every simple tool to handle > failures of close() without short-cutting the checking of following > closes and cleanup work would just be an absurd waste of time. Gonna side with Ian on this one. I took my queues from Rochkind (I think that's who it was) that wrote the Advanced Unix Programming - when I read that I was amazed at how many error returns he didn't check. I slowly learned that he checked the ones that could throw errors where he could do something about it and ignored the other ones. Mindlessly checking everything leads to dumb programming. I've seen the same thing in POSIX compliance testing. Zillions and zillions of mindless tests that somehow manage to not test the stuff that needs testing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171230172047.GK22177>