bogotune broken? Larger data* revision committed to CVS.

[Matthias Andree]

On Sun, 21 Nov 2004, David Relson wrote:

> On Mon, 22 Nov 2004 01:52:41 +0100
> Matthias Andree wrote:
> 
> > I've occasionally used setjmp/longjmp as well as sigsetjmp/siglongjmp
> > (for signal handlers) and it's always worked for me. We could use
> > these if the _exit in db_lock.c is too hard.
> 
> I've used them too, but it's been years.  As I recall dealing with
> memory allocation issues (possible leaks due to lack of free() calls)
> goes with using them carelessly.

Indeed, it'll just drop auto variables but not call free() on them. For
exit paths, when the program doesn't last long after the longjmp, it's
good enough though. An alternative would be to use a garbage collector
(Boehm-Demers-Weiser conservative garbage collector, used for instance
in GCC) but I'm not sure how it would impact peak memory usage or
performance.

> True enough.  However it _does_ catch a lot.  As much as I may
> complain about it, I thank you sincerely for adding it to
> bogofilter.
> 
> Complete coverage would require bogotune tests which need lots of
> messages and lots of run time.  'Tisn't feasible :-<

It's not so easy to trigger all the error recovery paths anyways.
Some errors are hard to trigger - how do I simulate EIO, for instance?

We may not be able to get the test suite check everything even if we can
pinpoint the areas that it doesn't run (through the use of coverage
analysis, gcov for instance) no matter how hard we try. For those areas,
simple regression checks must suffice. Write a test for the specific
bug before we start fixing it, to make sure it doesn't come back
unnoticed.

-- 
Matthias Andree