Re: [hypermail] Bug in hashreplynumlookup()

 cradle_at_glue.umd.edu (David Eisner) writes:
>messages have subject "Help". Ultimately the 'maybereply' flag in the
>reply struct is set to 1.
>
>Later on, in the FASTREPLYCODE version of crossindexthread2(), the message
>is dropped because rp->maybereply is 1 (actually, maybereply's are dropped
>only if at least one other reply to a message is a definite reply).

 The only clear-cut bug was in crossindexthread2. Now that I have removed the maybereply check from there, it's hard to tell whether your patch improves the threading. I've tested it on 2 archives, and see slightly more cases where it improves the threading (by not linking unrelated messages that have the same subject) than harms it (by failing to link replies which fail to add a Re: to the subject line and lack In-Reply-To's.  My guess is that the latter problem results from an obsolete mailer that is overrepresented in my tests, so I will probably incorporate your patch.

 On a related problem, hashreplylookup doesn't find as many matches as hashreplynumlookup does. The result is that some messages threaded as maybereply's have no "maybe in reply to" link. The functions apparently were at one time intended to return the same matches, and only differ in returning a pointer versus a number.
 Does anyone know of a reason why I shouldn't make them both use the logic of hashreplynumlookup?

-- 
------------------------------------------------------------------------------
Peter McCluskey          | Fed up with democracy's problems? Examine Futarchy:
http://www.rahul.net/pcm | http://hanson.gmu.edu/futarchy.pdf or .ps