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

[Mark Millard]

On 2017-Dec-31, at 7:05 PM, Rodney W. Grimes <freebsd-rwg at pdx.rh.CN85.dnsmgr.net> wrote:

>> Poul-Henning Kamp phk at phk.freebsd.dk wrote on
>> Sat Dec 30 20:35:35 UTC 2017 :
>> 
>>> But if you just close a file, and you're 100% sure that will work,
>>> you should write it as:
>>> 
>>> 	assert(close(fd) == 0);
>>> 
>>> To tell the rest of us about your assumption and your confidence in it.
>> 
>> Quoting the FreeBSD assert man page:
>> 
>> QUOTE
>>     The assert() macro	may be removed at compile time by defining NDEBUG as a
>>     macro (e.g., by using the cc(1) option -DNDEBUG).
>> ENDQUOTE
>> 
>> This makes required-actions inside asserts dangerous,
>> at least without guarantees that NDEBUG will be
>> undefined. Trying to guarantee that NDEBUG will be
>> undefined would generally be a bad idea.
>> 
>> So,
>> 
>> assert(close(fd) == 0);
>> 
>> is a bad coding practice in my view.
> 
> Less bad than either of
> 	(void)close(fd));
> 	close(fd);

Hmm. If one is not to check the status code,
then just do not close the file, at least for
NDEBUG style compiles. Seems odd to me.

"assert" indicates optional code, not required
code. (This is despite its name.)

In my view: Both errors need to be avoided and
my point still stands: the example is not a
reasonable way to code.

One could invent an alternate to assert under
a related name that does not make code
disappear (not even for NDEBUG). "assert"
is just not the right facility to express
just:

tell the rest of us about your assumption and your confidence in it

without also indicating: optional code.

===
Mark Millard
markmi at dsl-only.net