2009.02.06 16:33 "Re: [Tiff] assertions, and building with DEBUG/NDEBUG", by Bob Friesenhahn

On Thu, 5 Feb 2009, Phillip Crews wrote:

In a library like libtiff, it is inappropriate to abort the calling program when an assertion is triggered, which a failed assert() does on many platforms.

In my code, I use my own macro, which is defined as assert() in debug builds, but in release builds calls an internal logging routine and continues. If a severe problem or crash occurs later because of the bad value, I have information to go on in the log.

It is quite often (most often) not appropriate to proceed with processing once an assert has been encountered. Doing to risks heap corruption, and potential exploits from intentionally malligned files. If any heap or stack corruption has occured, then the process is then in an instable state.

The key thing is to discriminate between issues which are best reported as errors, warnings, or assertions. Assertions should always stop processing since they should be used to detect logic (i.e. design/implementation) errors. Warnings result in a message to the user, but processing continues. Errors result in a message to the user, and a return to the invoking code with no further processing of the current file.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/