[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enabling compiler warning flags

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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]