From owner-freebsd-hackers@freebsd.org Mon Jan 1 16:20:54 2018 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 BF043EB100F for ; Mon, 1 Jan 2018 16:20:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-112.reflexion.net [208.70.210.112]) (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 1439E723D9 for ; Mon, 1 Jan 2018 16:20:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 721 invoked from network); 1 Jan 2018 15:54:12 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Jan 2018 15:54:12 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 01 Jan 2018 10:54:12 -0500 (EST) Received: (qmail 10890 invoked from network); 1 Jan 2018 15:54:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Jan 2018 15:54:11 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3154CEC8E10; Mon, 1 Jan 2018 07:54:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? From: Mark Millard In-Reply-To: <69801.1514801240@critter.freebsd.dk> Date: Mon, 1 Jan 2018 07:54:10 -0800 Cc: "Rodney W. Grimes" , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <6658FD9E-3170-4249-8AEC-002E112473F4@dsl-only.net> References: <201801010305.w0135luG084158@pdx.rh.CN85.dnsmgr.net> <559541DD-3287-4473-B7DE-B4DDC6860DF7@dsl-only.net> <5AD2D86A-2515-4D4D-91B2-1919531F7CC3@dsl-only.net> <69801.1514801240@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3273) 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: Mon, 01 Jan 2018 16:20:54 -0000 On 2018-Jan-1, at 2:07 AM, Poul-Henning Kamp = wrote: > -------- > In message <5AD2D86A-2515-4D4D-91B2-1919531F7CC3@dsl-only.net>, Mark = Millard wr > ites: >=20 >> asserts that call abort are difficult to >> guarantee specific program-exit behavior >> for, based on just the standards anyway. >=20 > One should read "assert" in a source code as a curse along the lines = of > "Strike me by lightning if this is not true!" >=20 > If you want more gentle behaviour you should implement proper = errorhandling. >=20 > But for all the places where you think "Nahh ... that's never going to > happen", you should document your decision with assert(). (I'm ignoring the NDEBUG issue here.) Just be sure that for your context of use that the consequences of failure can be tolerated. Even the vintage of linux glibc matters: http://man7.org/linux/man-pages/man3/abort.3.html says: (note the reference to deadlocks and data corruption) Up until glibc 2.26, if the abort() function caused process termination, all open streams were closed and flushed (as with fclose(3)). However, in some cases this could result in = deadlocks and data corruption. Therefore, starting with glibc 2.27, = abort() terminates the process without flushing streams. POSIX.1 permits either possible behavior, saying that abort() "may include an = attempt to effect fclose() on all open streams". =3D=3D=3D Mark Millard markmi at dsl-only.net