|
From: | Bob Friesenhahn |
Subject: | Re: Enabling compiler warning flags |
Date: | Thu, 20 Dec 2012 17:13:16 -0600 (CST) |
User-agent: | Alpine 2.01 (GSO 1266 2009-07-14) |
On Thu, 20 Dec 2012, Jeffrey Walton wrote:
The "falling victim to runtime assertions" is the same as falling victim to a bug. It is not necessarily true that removing the assertion is better than suffering from the unhandled bug. Once again this is a program/situation-specific issue.Well, I can't think of a situation where an abort or crash is preferred over gracefully handling a failure that could be handled with an exit. In this case, the program is already in a code path - why not just fail the function rather than abort? But then again, I don't think like many others (as you can probably tell). So I could be missing something.
Assertions are intended for detecting unexpected conditions. External inputs to the program do not count as 'unexpected condition' and so one should never write an assertion for external inputs. When an unexpected condition occurs, the best thing to do is to dump core so that it is possible to figure out how the impossible happend.
I agree with Russ Allbery that the primary reason to disable assertions is to avoid the performance penalty. In properly-written code (such as your own) these assertions should not be firing anyway.
In my own performance-tuned software which uses many assert statements, I find the performance benefit from removing assertions to be virtually unmeasurable.
Bob -- Bob Friesenhahn address@hidden, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
[Prev in Thread] | Current Thread | [Next in Thread] |