Is it considered to be ok to not check the return code of close(2) in base?

Stefan Esser se at freebsd.org
Wed Jan 10 10:26:37 UTC 2018


Am 08.01.18 um 19:00 schrieb Rodney W. Grimes:
>> 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.
> 
> I agree with that.
> 
>>> 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.
> 
> Ok, so lets get a bit more clever,
> #ifdef DEBUG_CLOSE
> #define	close(f)	assert(close(f) && errno != EBADF)
> #endif

This will lead to close() being removed from the program,
if NDEBUG is defined ...

So, at least test for NDEBUG in addition to DEBUG_CLOSE,
to enable this macro.


More information about the freebsd-hackers mailing list