From owner-freebsd-hackers@freebsd.org  Fri Jan  5 22:26:43 2018
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 4C677EC4DC8
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Fri,  5 Jan 2018 22:26:43 +0000 (UTC)
 (envelope-from eric@vangyzen.net)
Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146])
 by mx1.freebsd.org (Postfix) with ESMTP id AA19A2B14;
 Fri,  5 Jan 2018 22:26:40 +0000 (UTC)
 (envelope-from eric@vangyzen.net)
Received: from sweettea.beer.town (unknown [76.164.8.130])
 by smtp.vangyzen.net (Postfix) with ESMTPSA id 43F045646F;
 Fri,  5 Jan 2018 16:26:25 -0600 (CST)
Subject: Re: Is it considered to be ok to not check the return code of
 close(2) in base?
To: Eugene Grosbein <eugen@grosbein.net>, Brooks Davis <brooks@freebsd.org>,
 Alan Somers <asomers@freebsd.org>
Cc: Yuri <yuri@rawbw.com>, Ian Lepore <ian@freebsd.org>,
 Freebsd hackers list <freebsd-hackers@freebsd.org>
References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com>
 <1514572041.12000.7.camel@freebsd.org>
 <CAOtMX2jSonHQ9xzVD3Q9XS2twBm_CT3Tquwn+f6zmc7aV0QerQ@mail.gmail.com>
 <20180105221330.GD95035@spindle.one-eyed-alien.net>
 <5A4FF989.1040709@grosbein.net>
From: Eric van Gyzen <eric@vangyzen.net>
Message-ID: <7b977409-96ee-5acb-60d0-3b0e124495f0@vangyzen.net>
Date: Fri, 5 Jan 2018 16:26:23 -0600
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5A4FF989.1040709@grosbein.net>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Fri, 05 Jan 2018 22:26:43 -0000

On 01/05/2018 16:17, Eugene Grosbein wrote:
> 06.01.2018 5:13, Brooks Davis wrote:
> 
>>> I would argue the opposite.  There are very few reasons why close(s) would
>>> ever fail, and the most likely is EBADF.  EBADF indicates a programming
>>> bug, like a double close or use of an uninitialized variable.  Those could
>>> easily turn into worse bugs in the future.  So I think the best course of
>>> action is to check the return code, assert() on EBADF, and ignore, or
>>> possibly log, other errors.
>>
>> For this specific case, I think there would be value in an option to
>> have the kernel kill any process that calls close(fd) where fd != -1
>> where EBADF would be returned.
> 
> A medicine should not be worse worse than the disease, imho.

In a multi-threaded application, a double-close can close completely
unrelated file descriptors, which can be a nightmare to diagnose.  In
that case, death by signal is far better than the disease.

Eric