I think you missed the point: I agree that using assert() is good for declaring invariants - but it is used only at debugging (as the quoted text says). If you don't turn assert() off at production (NDEBUG) you are in a deeper problem. The main thing should be that assert() does not replace if() or other conditionals (say for testing successful scanf()), and moreover, assert() should be used in a textbook when teaching debugging - not when teaching the basics of programming (likewise, only a very advanced student-driver is taught how to restart a stalled engine while in 60mph motion on the freeway - not a beginner one).

> If you don't turn assert() off at production (NDEBUG) you are in a deeper problem

In a deeper problem compared to when I don't turn it off? Are you sure about that? The only reason asserts are turned off in the production code is the performance considerations, nothing else.

Sorry to hear that. The problem with assert() at production code is that it crashes the program. IMNSHO, it's a medicine worse than the disease (is this why we get a "blue screen" on a popular OS?). Most, if not all tools should be lenient about errors - both user errors and system/environment errors - not just safety systems. There are very few cases that a tool should say "there is a problem, please contact the vendor" - and even then it is unreasonable to do it while crashing (maybe the user is willing to give up the last task but wants to start over with a different task). If you are not convinced, I am not able to explain it in any simpler and clearer way. Thanks for your time.

"Sorry to hear that"? Seriously?

You have fundamental misunderstanding of what asserts() are for. As GP said, they check for invariants not errors. Here -

  +--------------------------------+
  |                                |
  |   ASSERTS ENFORCE INVARIANTS   |
  |                                |
  +--------------------------------+

They aren't meant for checking if socket() returned -1 or user entered an empty string. These are not invariants. An invariant is a condition that must always hold true or the code that follows will go off rails. An ordered list to be ordered, a pointer passed to a function to be pointing at a valid and consistent representation of a respective data type... this sort of thing. A foo(void * ptr) not being called with NULL may or may not be an invariant depending on what foo's documentation states. For internal code it probably will be, for a library version is probably won't. In any case, these invariants is what you assert().

If your code runs into a broken invariant and you let it continue forward, you simply push the problem deeper and let it metastasize. Compare abort'ing program to letting it go on, fubar'ing user data and then over-writing a disk file with the resulting garbage. A medicine worse than a disease, eh?

Well, I find this discussion very interesting - esp. because it reveals so many misconceptions about programming in a tiny nutshell. Let me start by emphasizing that you were reading into the previous comment something the author didn't write. "If your code runs into a broken invariant and you let it continue forward ..." - I don't see anything even remotely associated with it: The claim was just that "abort()" in most cases is too strong a response. Indeed "ASSERTS ENFORCE INVARIANTS" - but during debugging. And invariants may be enforced using different mechanisms, assert(), as a very general tool/technique is simply and understandably very crude. My view of assert() is two fold: 1. It's a shotgun. In real life not every "crime" deserves capital punishment (and not all broken invariants are the same). 2. All asserts are connected: They can only be turned on/off together (yes, you may use conditional compilation to overcome this problem, but in this case conditional compilation can be used for just a better system - where there are various severity levels for asserts).

All you have to realize is that not all problems need the same cure. Using your example, if it is found that a list broke it's invariant, isn't it enough to stop using this list (isolating it, not freeing it) and then gracefully terminate the program? There is more to elaborate here, but most readers can draw the correct conclusions. Maybe this discussions exposes how much more we need to learn about software quality - where my page on bad books (the ones I have encountered) is just a very narrow opening to the real problems.