[cvs] bogofilter/tests/bogofilter t.grftest,1.6,1.7

[Matthias Andree]

On Wed, 29 Jan 2003, David Relson wrote:

> On the cosmic scale, t.grftest failed to detect the missing msgcount in 
> graham.c - the problem that Clint encounterd as a SIGFPE.  My guess is 
> that, with all the parser changes, I didn't check closely enough to see 
> _why_ the reference results needed to be updated.  Anyhow for versions 
> 0.10.0 through 0.10.1.2 t.grftest and t.systest are validating a busted 
> graham algorithm.  After hearing from Clint and Allyn, it'll be time to 
> decide whether to build/release 0.10.1.3 tonight or wait for additional 
> fixes.  Let me know if you have strong feelings one way or the other.

I don't have any bug fixes in the pipe, so I see no point in holding
back the release. If we find bugs after 0.10.1.3, we'll then decide what
to do.

The interesting thing about this is: it escaped our tests and it didn't
throw exceptions on either ix86 or sparc. But why not? Why did it take
a HP-PA RISC machine to ultimately throw that division by zero
exception? Because it was an integer?

Anyways, I wonder if we should initialize the fields in init_wordlist to
poisonous values if we expect them to be changed by the methods -- or
leave them uninitialized, so that valgrind can find them.

With the CVS as of 29 Jan 12:00 UTC, removing the bogus msgcount=0
initialization gives valgrind "results" quick:

$ echo "test blah sülz" | valgrind -q ./bogofilter -g 
==28803== Use of uninitialised value of size 4
==28803==    at 0x8049CF6: compute_probability (graham.c:224)
==28803==    by 0x8049DA7: select_indicators (graham.c:256)
==28803==    by 0x8049F7C: gra_bogofilter (graham.c:333)
==28803==    by 0x804950F: bogofilter (bogofilter.c:72)

I'll see if I can concoct a test to address this without too much
effort.

-- 
Matthias Andree