From owner-freebsd-hackers@freebsd.org Sat Dec 30 17:29:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54BC6EA3C4F for ; Sat, 30 Dec 2017 17:29:44 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42CC963D4A; Sat, 30 Dec 2017 17:29:44 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: by mcvoy.com (Postfix, from userid 3546) id 2466235E0DC; Sat, 30 Dec 2017 09:20:47 -0800 (PST) Date: Sat, 30 Dec 2017 09:20:47 -0800 From: Larry McVoy To: Ian Lepore Cc: "Rodney W. Grimes" , Eugene Grosbein , Yuri , Freebsd hackers list 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> References: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> <1514654174.12000.15.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1514654174.12000.15.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 17:29:44 -0000 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.