bogotune broken? Larger data* revision committed to CVS.

[David Relson]

On Mon, 22 Nov 2004 01:52:41 +0100
Matthias Andree wrote:

> David Relson <relson at osagesoftware.com> writes:
> 
> > The following works (although the compiler complains about the
> > externs).
> 
> That's probably not for the earlier ANSI-C (C89) compilers.
> 
> > .  It limits knowledge of the variable and gives the appearance of
> > accessors without any speed penalty.  However, it really isn't very
> > useful :-<
> 
> Speed isn't our concern except in loops that are executed often, and
> there we can usually cache the variable. It's really the global
> variable that is an issue.
> 
> For instance, we might store all the stuff that is read from the
> configuration in a struct and pass a pointer to that struct, rather
> than checking globals. It may not make a huge difference at first, and
> I'm not urging towards an immediate complete replacement of globals,
> but it becomes easier as we start splitting things up that used to be
> a single unique resource per process, for instance, the environment.

I'm skeptical.  We could well add a globals structure, for example
"typedef ... bogo_globals_t", for holding all the config parms.  Then we
could add a"bogo_globals_t *pAllGlobals" as needed (and I suspect it
would be widely needed).  Doing this removes explicit globals, but
allows a whole lot of access to the actual values.  I guess I'd have to
see it in action to accept it.  In any case, it's not for version 1.0

...[snip]...

> >> Poor man's exceptions are called setjmp ("try/catch" in one) and
> >> longjmp("throw") and the sig* variants. They're even ANSI-C which
> >has> been around for 15 years so there'll be no excuse if some system
> >> doesn't have these. :-)
> >
> > I considered them, but shied away...
> 
> 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.

> > I've got code with a wordlists open/closed flag and a test in
> > bf_exit().
> >  "make check" indicates bf_exit() isn't needed.
> 
> Make check isn't complete, but we don't have 100% test coverage at any
> rate.

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 :-<

> > P.S. I'll add '-x' support to bogotune.  If recollection serves, it
> > only takes a line or two of code.
> 
> Thanks a bunch.

De nada.