AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

2009.02.05 18:38 "assertions, and building with DEBUG/NDEBUG", by Frank Warmerdam
2009.02.05 19:04 "Re: assertions, and building with DEBUG/NDEBUG", by Edward Lam
2009.02.05 19:13 "Re: assertions, and building with DEBUG/NDEBUG", by Bob Friesenhahn
2009.02.05 19:26 "Re: assertions, and building with DEBUG/NDEBUG", by Frank Warmerdam
2009.02.05 20:00 "Re: assertions, and building with DEBUG/NDEBUG", by Bob Friesenhahn
2009.02.06 04:39 "Re: assertions, and building with DEBUG/NDEBUG", by Phillip Crews
2009.02.06 16:33 "Re: assertions, and building with DEBUG/NDEBUG", by Bob Friesenhahn
2009.02.06 20:34 "Re: assertions, and building with DEBUG/NDEBUG", by Phillip Crews
2009.02.06 12:17 "Re: assertions, and building with DEBUG/NDEBUG", by <ron@debian.org>
2009.02.06 13:57 "Re: assertions, and building with DEBUG/NDEBUG", by Edward Lam
2009.02.06 17:08 "Re: assertions, and building with DEBUG/NDEBUG", by Bob Friesenhahn
2009.02.06 21:05 "Re: assertions, and building with DEBUG/NDEBUG", by Phillip Crews
2009.02.06 10:07 "Re: assertions, and building with DEBUG/NDEBUG", by Joris Van Damme
2009.02.06 15:05 "Re: assertions, and building with DEBUG/NDEBUG", by Frank Warmerdam
2009.02.06 10:44 "Re: assertions, and building with DEBUG/NDEBUG", by Joris Van Damme
2009.02.06 14:56 "Re: assertions, and building with DEBUG/NDEBUG", by Frank Warmerdam
2009.02.07 10:53 "Re: assertions, and building with DEBUG/NDEBUG", by Joris Van Damme
2009.02.07 14:10 "Re: The OJPEG bug 1996", by Joris Van Damme
2009.02.26 22:44 "Re: assertions, and building with DEBUG/NDEBUG", by Joris Van Damme

2009.02.06 12:17 "Re: assertions, and building with DEBUG/NDEBUG", by <ron@debian.org>

On Thu, Feb 05, 2009 at 02:00:58PM -0600, Bob Friesenhahn wrote:
> On Thu, 5 Feb 2009, Frank Warmerdam 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