Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.std.c Subject: Re: ANSI assert Keywords: assert, NDEBUG Message-ID: <3726@goanna.cs.rmit.oz.au> Date: 11 Sep 90 07:22:36 GMT References: <1428@proto.COM> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 35 In article <1428@proto.COM>, joe@proto.COM (Joe Huffman) writes: > In the latest version of 'The C User Journal' P.J. Plauger wrote about the > assert 'function' under ANSI C. ... It appears > to me that [Plauger's code] is wrong (it would break nearly all of my code). > My concern is when NDEBUG is defined. I have many places in my code where I > do something like the following: > assert(i++ < limit); > either someone overlooked a potential problem or my coding > style is going to have to be revised (as well as 10's of thousands of lines > of code). Your code is *ALREADY* broken. The ``de facto'' standard in UNIX has been #ifdef NDEBUG #define assert(ex) /**/ #else ... #endif or something very like it for a long time. For many people it has been important that the test *not* be evaluated when NDEBUG is defined; if the tests are cheap enough that you want them to be done anyway you would be rather silly to do all that work and not take advantage of it! A common case is assert(very_costly_checking_call()); where the _point_ of NDEBUG is to avoid the call when not debugging. The argument of assert() has no business producing side effects. Quite apart from assert being a macro rather than a function, assert() is supposed to be used the way you would use assertions, and assertions are *pure* boolean formulas. The "discourse convention" used by human beings is that assertions are comments about the code, not an integral part of it, so if you put side effects in your assert()s your _human_ readers are going to be very confused by it. -- Heuer's Law: Any feature is a bug unless it can be turned off.