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