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

[Eugene Grosbein]

06.01.2018 5:26, Eric van Gyzen 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.

A kernel cannot know if close() was called for "unrealated" but correct file descriptor.