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 21:05 "Re: assertions, and building with DEBUG/NDEBUG", by Phillip Crews
Bob Friesenhahn wrote: > On Fri, 6 Feb 2009, Ron wrote: > >> 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 >> > > Assert is like an electric cattle-prod for libtiff developers to > motivate them to fix problems. For example, a common assertion is for > a function to test if a passed pointer is not NULL prior to using it. > If the passed pointer is NULL, then there must have been a logic error > in some other part of the code (e.g. not checking the value from > malloc/realloc) or memory containing the pointer was overwritten to > zero. I have several systems here which will dereference through a > null pointer without automatic assertion so an explicit assertion is > valiable. > > If problems which should really be assertions are instead reported as > a warning or even an error, then it is likely that most users will not > report the problem, and so it won't be fixed. In some cases written > files may become corrupted, potentially at huge loss to the user. > Clearly a thrown assertion is preferable over writing a corrupt file. > As with input validation, I think anything detected during writing of the file should return an error to the application, giving some chance of recovery. Often the only copy of the image data they are trying to write is in memory; aborting the entire application has, in most cases, consequences just as bad as writing a corrupt file. > The vast majority of users who encounter a problem do not report it to > responsible parties. > Well, they can't report it if they don't see it! Most end users will either not see the error because libtiff was compiled with NDEBUG (so no test is done and no message is generated), or not see it because stderr is not visible (GUI applications / daemons), or not understand anything except that the application crashed. As pointed out by the assert man page, "The message 'assertion failed in file foo.c, function do_bar(), line 1287' is of no help at all to a user." This is why I think that the application needs to be given some modicum of control. > At the moment there are 363 assert statements in libtiff. > Investigation will likely show that most of these assert statements > have been in the code for many years, without causing any harm. > I certainly hope the problem asserts are a small subset! > It seems that Joris and perhaps other libtiff developers have a > somewhat different idea of assert than that it is like an electric > cattle prod to get serious logic problems noticed and fixed ASAP. > Asserts which validate data read from a file are a serious bug. > Speculative asserts are a serious bug. > > The libtiff project cuts alpha and beta packages and encourages people > to test with them in order to discover any problems (such as thrown > assertions) prior to release. > As always, end users will find cases that library users/developers don't. - Phillip