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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
