Date: Mon, 14 Oct 2002 12:04:46 -0400 (EDT)
From: Scott Lipcon <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I submitted this bug last week, and added an update today. I don't
| think anyone's really using savannah's bug tracking tool, so I'm
| forwarding this to the nmh-workers list.
Try the following patch to uip/sortm.c
The "korean spam" part of the message (if that's what it was)
is irrelevant, the same thing would happen to any message that
had a Subject header like
Subject:N...
where 'N' is any alphanumeric character.
The patch below adds a #if 0 to remove a line of code (or two). You can
change it to "#if 1" if you prefer, to eliminiate a different line of code.
Either line is acceptable, from the no core dump, point of view, but both
together are fatal.
This code is attempting to eliminate "Re:" from Subject lines before
comparing them. It looks as if that was attempting (once) to get rid
of multiple instances of "Re:". Someone then probably noticed that this
would also get rid of "Re:" in a context like "more:" which isn't what
is intended... So, my guess is, the "break" was added so the "Re:"
skipping would be done only at the beginning of the Subject line, not
anywhere else inside it. Unfortunately, that was not well done.
(Another fix for this would be to add a "cp++" in an appropriate place
before the bug.
What happens is that cp2 moves ahead of cp, and the code as written
assumes that that is impossible. Something has to prevent that from
happening (once it does, the loop a few lines lower spends to eternity,
or a core dump, whichever occurs first, chasing its tail).
kre
--- sortm.c.WAS Tue Oct 15 15:18:47 2002
+++ sortm.c Tue Oct 15 15:20:11 2002
@@ -439,9 +439,12 @@
if(uprf(cp, "re:"))
cp += 2;
else {
+#if 0
if (isalnum(c))
*cp2++ = isupper(c) ? tolower(c) : c;
+#else
break;
+#endif
}
}
cp++;
