Date: Mon, 8 Jan 2018 11:51:56 -0600 From: Eric van Gyzen <eric@vangyzen.net> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, Eugene Grosbein <eugen@grosbein.net> Cc: Brooks Davis <brooks@freebsd.org>, Alan Somers <asomers@freebsd.org>, Yuri <yuri@rawbw.com>, Ian Lepore <ian@freebsd.org>, 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: <df6f98a5-76db-d6d8-6321-d35b59eeec22@vangyzen.net> In-Reply-To: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net> References: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/08/2018 10:55, Rodney W. Grimes wrote: >> 08.01.2018 23:13, Eric van Gyzen wrote: >> >>> Right, which is the reason such bugs are hard to diagnose. Optionally >>> killing the process on close->EBADF would help find buggy code when >>> another thread did NOT re-open the file descriptor between the two close >>> calls. >> >> Wouldn't "close(f); assert(errno != EBADF);" be better? Putting the code in one place is far better than putting it in N places...after /finding/ those N places. Indeed, the purpose of this code is to help people find those places, even in their own code, outside of base. > Or even > #ifdef DEBUG_CLOSE > #define close(f) close(f); assert(errno != EBADF); > #endif errno could have been EBADF before the close(). A successful close() does not modify errno. So, this would have be larger, making it even more unpalatable. > Then the people that want to go chasing these errors can, > and the rest of us are untouched. Every mention in this thread of killing the process has called it optional. Tools, not policy. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?df6f98a5-76db-d6d8-6321-d35b59eeec22>