Date: Mon, 1 Jan 2018 07:48:03 -0800 From: Mark Millard <markmi@dsl-only.net> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <510305A9-460C-407F-B2FC-3521A6E1D78B@dsl-only.net> In-Reply-To: <69781.1514800992@critter.freebsd.dk> References: <201801010305.w0135luG084158@pdx.rh.CN85.dnsmgr.net> <559541DD-3287-4473-B7DE-B4DDC6860DF7@dsl-only.net> <69781.1514800992@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Jan-1, at 2:03 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> = wrote: > -------- > In message <559541DD-3287-4473-B7DE-B4DDC6860DF7@dsl-only.net>, Mark = Millard wr > ites: >=20 >> "assert" indicates optional code, not required >> code. (This is despite its name.) >=20 > 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. >=20 > 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) =3D=3D 0); use code like: close_status=3D close(fd); assert(close_stats=3D=3D0); 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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?510305A9-460C-407F-B2FC-3521A6E1D78B>