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

[Eric van Gyzen]

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