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:57, Eugene Grosbein wrote:
> 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.

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.

Eric