t.lock2 issues

[Clint Adams]

----- Forwarded message from aaronl at vitelus.com -----

Package: bogofilter
Version: 0.10.1.4-1
Severity: normal

If bogofilter can not lock a database, it waits a random amount of
time between MIN_SLEEP and MAX_SLEEP. At least, that's how it works in
theory. A bug causes it to sleep for MIN_SLEEP microseconds virtually
always. (MAX_SLEEP-MIN_SLEEP) is multiplied by rand(), and with the
current values of MIN_SLEEP and MAX_SLEEP this almost always causes a
long integer overflow on 32 bit systems. The result is then divided by
(RAND_MAX+1.0), but as the maximum value of a signed long integer on
my platform is equal to RAND_MAX, this division is useless and will
always have a zero result. The patch below solves the problem by doing
the multiplication with floating point arithmetic, preventing integer
overflow.

Note that bogofilter does not seem to seed the rand() function. This
shouldn't really be necessary, but it does make the t.lock2 test less
effective, since every instance of bogofilter will use the same random
number sequence. (Alternately, you can view this as beneficial to the
test, since every bogofilter process will sleep for the same time and
thus there will be more lock contention when they awake simultaneously).

diff -ru bogofilter-0.10.1.4/wordlists.c bogofilter/wordlists.c
--- bogofilter-0.10.1.4/wordlists.c     2003-01-30 18:46:01.000000000 -0800
+++ bogofilter/wordlists.c      2003-01-31 18:41:33.000000000 -0800
@@ -125,7 +125,7 @@
                        {
                            struct timeval to;
                            long delay = MIN_SLEEP + (long)
-                               ((MAX_SLEEP-MIN_SLEEP)*rand()/(RAND_MAX+1.0));
+                               ((float) (MAX_SLEEP-MIN_SLEEP)*rand()/(RAND_MAX+1.0));
 
                            to.tv_sec  = delay / 1000000;
                            to.tv_usec = delay % 1000000;


----- End forwarded message -----