question about config code

[David Relson]

At 03:52 PM 11/25/02, Graham Wilson wrote:

>On Mon, Nov 25, 2002 at 07:49:30AM -0500, David Relson wrote:
> > Each entry in the parm_desc struct has a "type" field (CP_ALGORITHM,
> > CP_INTEGER, etc).  A switch statement branches on the type and either does
> > inline processing to get a value and store it (for simple types like
> > CP_INTEGER, CP_DOUBLE, etc), or it calls a function to process the
> > parameter (for CP_ALGORITHM and CP_WORDLIST).
>
>it would seem to me both from looking at the code and from stepping
>through it in gdb that the CP_ALGORITHM case is never reached, since
>algorithm has a NULL in its addr field, which causes
>process_config_parameter to pass return before even reaching the switch
>statement:
>
>         if ( arg->addr.v == NULL )
>                 return ok;

Gram,

It's working fine for me.  I'm sitting right now with gdb stopped by a "b 
select_method" statement.

Have you tried the patch I sent you with debugging turned on?  What does it 
print?

You mention gdb.  Are you perchance using it to step through optimized 
code?  Since optimized code is reordered, stepping through it is a 
deceptive nightmare.  When I'm ready to debug, I remove the optimization 
from CFLAGS, run "make clean" and then "make"


> > Some options apply to bogofilter as a whole.  Some apply to a particular
> > algorithm, but not to the others.  The parm_desc struct in config.c gives
> > the handling info for the global parameters.  The algorithm files
> > (graham.c, robinson.c, and fisher.c) have their own parm_desc structs for
> > their private parameters.
>
>it would seem to make more sense to handle the option processing from
>config.c, but i guess it is done this way so that all algorithm code can
>be properly seperated from the rest of the code, right?

That breaks any semblance of encapsulation and obscures the code by adding 
lots more #ifdefs.  The code was that way, until I restructured it, 
applying object oriented principles to the C code.

David