Bug: multipart.sl macro does not behave as advertised

[Jörg S. <jo...@al...>]

Hi John,

in Debian Bug Tracker contains this report for a while:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445258

|The multipart.sl macro included with slrn does not behave correctly.
|When a binary file specifies both a file number and a part number in the
|subject line, the part numbers are not grouped into a single thread as
|the macro suggests.  For example, a subject of:
|
|Binary file (##/20)
|
|will work fine with the multipart.sl macro, but the subject line:
|
|Binary [1/10] First file part (##/20)
|
|will not be grouped properly into the same thread.
|
|The multipart.sl macro has not changed since the 0.9.8.1-6 release in
|sarge, where this bug did not exist.  However the etch version
|(0.9.8.1pl1-28) has been built against s-lang 2 rather than s-lang 1.
|This change to s-lang 2 suggests that multipart.sl must be fixed to work
|with s-lang 2 properly.

Brian Murray from Ubuntu provided a patch and I think, you should apply
it. I couldn't find any informations about the old behaviour of
string_match() and if the macro multipart.sl could have worked as
announced ever. But I think the fix is correct.

#v+
--- /usr/share/slrn/slang/multipart.sl	2009-06-15 13:43:00.000000000 -0700
+++ multipart.sl	2009-08-24 07:53:36.000000000 -0700
@@ -40,7 +40,7 @@ define subject_compare_hook ( subject1, 
 
    while (tmp > 0)
    {
-      pos1 = pos1 + 4 + tmp;
+      pos1 = tmp;
       tmp = string_match(subject1, pattern, pos1 + 5);
    }
 
@@ -48,7 +48,7 @@ define subject_compare_hook ( subject1, 
    tmp = string_match(subject2, pattern, pos2 + 5);
    while (tmp > 0)
    {
-      pos2 = pos2 + 4 + tmp;
+      pos2 = tmp;
       tmp = string_match(subject2, pattern, pos2 + 5);
    }
         
#v-

Bye, Jörg.
-- 
Nicht was Du bist, ist es was Dich ehrt, wie Du bist bestimmt den Wert.
Wünsche hat man oft und viel, nur wer lernt erreicht sein Ziel.