2009.02.06 12:17 "Re: [Tiff] assertions, and building with DEBUG/NDEBUG", by Ron

On Thu, Feb 05, 2009 at 02:00:58PM -0600, Bob Friesenhahn wrote:

I have not heard of a build production process for open-source based systems which intentionally disables assertions. More than likely they are disabled in quite a few closed-source applications.

It has always been my practice and assumption that assertions should be disabled in production software where performance and appropriate error handling is considered important.

Perhaps open-sourced operating systems are not really production software. :-)

Or perhaps hard assertions aren't really intended for things you can actually ignore :)

My own software contains quite a lot of assertion statements but the performance boost from removing them was only a few percent. Quite a lot of the influence on performance is if the values checked will be immediately used or not. If the values will be immediately used then the assertion is almost free since the first access to the value is most of the cost. If the value is off in some data structure which is otherwise rarely used, then the cost may be rather high.

An assert that will summarily terminate the running process really only belongs where there is no possibility of recovering from the error.

Ignoring such errors on production systems seems most unwise, since you are replacing a controlled bail-out with undefined behaviour. If the result of that wasn't undesirable, you probably didn't need the hard assert in the first place.

Regardless, I think that it should be up to the person building libtiff to decide if NDEBUG should be applied, and that it should not be the default.

I agree, tiff should never change the value of NDEBUG. If we do, it will cause the behaviour of other projects using tiff to change silently.

If asserts are causing trouble at runtime, for things that can be ignored or recovered from, then we should just use a different warning mechanism in those places. Having a TIFFDEBUG that developers can define to get the extra warnings from tiff that production systems can ignore seems better than relying on a global that we don't really own.

assert() isn't very friendly even to developers. really we should only be using it where it is "impossible" for the test to fail, and there is no way to sanely recover if it does. If you are planning to drop that test for production systems, it really only makes sense where you can _prove_ that code which never made it fail in the past, will never make it fail in the future. asserting on the contents of input data makes no sense, you need to be able to recover from that in some way or another, and if you can recover from it on production systems, then it makes sense to recover (and warn) in 'development mode' too. The code is both simpler and less imposing on the developer (who may not care immediately about the assert, but still be interested in coming back to look at that later), if errors are handled that way.

I'd say drop the use of assert in most places and just forget NDEBUG exists is probably the best approach for libtiff. Libraries generally shouldn't terminate their calling process without a very good reason. We can't possibly know what data loss may occur if we don't let the caller do a managed shutdown of their own stuff.

Cheers,
Ron