LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.02.06 16:33 "Re: 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/