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

[Mark Millard]

On 2018-Jan-1, at 2:03 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> --------
> In message <559541DD-3287-4473-B7DE-B4DDC6860DF7 at dsl-only.net>, Mark Millard wr
> ites:
> 
>> "assert" indicates optional code, not required
>> code. (This is despite its name.)
> 
> Assert statements are not debugging, although they greatly help
> debugging, they are an integral part of the program, which documents
> for the maintainers and the running system what assumptions are
> being made.
> 
> Who ever added "#ifndef NDEBUG" not only failed Sensible Naming
> 101, they also totally misunderstood the nature of assert() as
> a programming construct.

None of us invented assert as it was
first historically created or as it is
in the standards. It possibly predates
pre-conditions, invariants, and the like
(e.g., predicate transformers) as a
programming technique. You are arguing
with a definition we are not in control
of if the standard's header is used (in
C or in C++).

It clearly was invented to allow avoiding
the performance consequences of the
contained expression. That suggests that
it was invented for debugging, like it
or not.

If one wants to use assert, then
instead of:

assert(close(fd) == 0);

use code like:

close_status= close(fd);
assert(close_stats==0);

to avoid the close disappearing if
NDEBUG is defined. Just a different
coding organization for that
specific point to be addressed.

(This does not deal with the
potential consequences of use of
abort() for assert failure,
especially code targeting
multiple environments.)

I wrote earlier: "One could invent
an alternate to assert under a
related name". You wrote: "Define
your own assert() macro." Other
than possible confusions over if
a long standing definition is in
use or not, these can address the
issues with assert.

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