debian.s390 problem

David Relson relson at osagesoftware.com
Thu Mar 27 06:08:14 CET 2003


Clint,

I've looked at the files in grftest.20030327 and think I know what the 
problem is.  In a nutshell, there appears to be a problem with 
strcspn().  I wonder if it's another gcc/s390 problem.

Below is my somewhat lengthy problem diagnosis.

David

### Diagnosis ###

After running "t.grftest -v" on my Mandrake 9.1 box, I ran command "diff 
-ur  ~/filter/deb.0326.d/s390.grftest.20030327 
~/filter/cvs/src/tests/bogofilter/grftest.20030326" to compare my 
Mandrake.i686 output to your Debian.s390 output.   Here's part of the output:

diff -ur 
/home/relson/filter/deb.0326.d/s390.grftest.20030327/tests/msg.1.t.v 
/home/relson/filter/cvs/src/tests/bogofilter/grftest.20030326/tests/msg.1.t.v
--- /home/relson/filter/deb.0326.d/s390.grftest.20030327/tests/msg.1.t.v 
2003-03-26 23:01:19.000000000 -0500
+++ 
/home/relson/filter/cvs/src/tests/bogofilter/grftest.20030326/tests/msg.1.t.v 
2003-03-26 23:24:53.000000000 -0500
@@ -1 +1 @@
-= h 4.71e-01
+u 0.470915

diff -ur 
/home/relson/filter/deb.0326.d/s390.grftest.20030327/tests/msg.2.t.v 
/home/relson/filter/cvs/src/tests/bogofilter/grftest.20030326/tests/msg.2.t.v
--- /home/relson/filter/deb.0326.d/s390.grftest.20030327/tests/msg.2.t.v 
2003-03-26 23:01:19.000000000 -0500
+++ 
/home/relson/filter/cvs/src/tests/bogofilter/grftest.20030326/tests/msg.2.t.v 
2003-03-26 23:24:53.000000000 -0500
@@ -1 +1 @@
-= h 5.00e-01
+u 0.500000

diff -ur 
/home/relson/filter/deb.0326.d/s390.grftest.20030327/tests/msg.3.t.v 
/home/relson/filter/cvs/src/tests/bogofilter/grftest.20030326/tests/msg.3.t.v
--- /home/relson/filter/deb.0326.d/s390.grftest.20030327/tests/msg.3.t.v 
2003-03-26 23:01:19.000000000 -0500
+++ 
/home/relson/filter/cvs/src/tests/bogofilter/grftest.20030326/tests/msg.3.t.v 
2003-03-26 23:24:53.000000000 -0500
@@ -1 +1 @@
-= h 5.00e-01
+u 0.500000

In all cases the different lines are outputs from "bogofilter -t ..." 
commands.  The "-t" option says to use "terse output".  The format for 
terse output is defined by options in config file "cfg.t" which is given here:

robx=0.415
min_dev=0.1
ham_cutoff=0.1
terse_format = %1.1c %d
spamicity_tags = S,h,u
spamicity_formats = %6.2e %6.2e %0.6f

Looking at these lines, it is apparent that parsing is broken where spaces 
surround equal signs.  Since this test passed for both the arm and powerpc 
architectures, this looks like a flaw particular to debian.s390.

In function read_config_file() in  file configfile.c, lines of the config 
file are broken into key,value pairs at lines 205ff.  Here's a code excerpt:

	const char delim[] = " \t=";
	size_t len;
	char buff[MAXBUFFLEN];

	...

	... fgets(buff, sizeof(buff), fp) ...

	...

	arg = buff;
	if (strcspn(arg, delim) < strlen(arg)) { /* if delimiter present */
	    val = arg + strcspn(arg, delim);
	    *val++ = '\0';
	    val += strspn(val, delim);
	} ...

Let's use the first problem line, i.e. "terse_format = %1.1c %d", for 
discussion.  In the above code, the calls to strcspn() should find the end 
of the keyword.  This appears to be working fine (as there are no parsing 
errors reported by bogofilter).  The call to strcspn() should skip over the 
spaces and the equals sign.  Variable "val" should have value "%1.1c 
%d".  However the output of diff, i.e. "-= h 4.71e-01" indicates that the 
equal sign is _not_ being skipped by strcpsn().

This appears to be a flaw in strcspn().  Since this test passed on both arm 
and powerpc, the problem appears to be s390 specific.   As the last s390 
problem was a gcc problem, I wonder if this is also a gcc 
problem.  Somebody need to dig deeper into strcspn() to see what's happening.
--------------------------------------------------------
David Relson                   Osage Software Systems, Inc.
relson at osagesoftware.com       Ann Arbor, MI 48103
www.osagesoftware.com          tel:  734.821.8800





More information about the bogofilter-dev mailing list