Date: Sat, 30 Dec 2017 10:16:14 -0700 From: Ian Lepore <ian@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, Eugene Grosbein <eugen@grosbein.net> Cc: 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: <1514654174.12000.15.camel@freebsd.org> In-Reply-To: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> References: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1514654174.12000.15.camel>