From owner-freebsd-hackers@freebsd.org Sat Dec 30 17:16:22 2017 Return-Path: <owner-freebsd-hackers@freebsd.org> 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 E2778EA3093 for <freebsd-hackers@mailman.ysv.freebsd.org>; Sat, 30 Dec 2017 17:16:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 C624463591 for <freebsd-hackers@freebsd.org>; Sat, 30 Dec 2017 17:16:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1bbdb620-ed85-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 1bbdb620-ed85-11e7-8486-0934409070aa; Sat, 30 Dec 2017 17:16:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBUHGEqr005863; Sat, 30 Dec 2017 10:16:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514654174.12000.15.camel@freebsd.org> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? 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> Date: Sat, 30 Dec 2017 10:16:14 -0700 In-Reply-To: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> References: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/> List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 30 Dec 2017 17:16:23 -0000 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