Fix from Robert Elz in PR 18664 to stop sortm coredumping when there's

a numerical subject.

"And yes, this really does add a preprocessor conditional that makes
either one of two original statements get compiled, and the other
omitted (ie:  the patch is correct, though just deleting a line would
work as well).  The "#if 0" could become "#if 1" and the core dump
would also be gone, though the results of the sort would then
sometimes be rather hard to explain..."

Bump PKGREVISION.

1 files changed, 36 insertions, 0 deletions

diff --git a/mail/nmh/patches/patch-ce b/mail/nmh/patches/patch-ce
new file mode 100644
index 00000000000..fd92e91af6c
--- /dev/null
+++ b/mail/nmh/patches/patch-ce
@@ -0,0 +1,36 @@
+$NetBSD: patch-ce,v 1.3 2002/10/15 10:47:00 agc Exp $
+
+Robert Elz's PR 18664 contains the rationale for this patch:
+
+        A bug report (from Scott Lipcon) was submitted elsewhere:
+http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=1393&group_id=2166
+        and then today copied to the nmh-workers list.
+
+        Basically, using "sortm -textfield subject" where a message
+        in the folder contains "Subject:N" where "N" is alphanumeric
+        will cause sortm to dump core (the "korean spam" aspect of the
+        mail that caused the original bug report is irrelevant).
+
+>How-To-Repeat:
+        Use nmh.   Put a message in a folder that contains "Subject:1234"
+        and then run
+                sortm +whatever-folder -textfield subject
+        and watch for the core dump.
+
+        Or, examine the code and be amazed ...
+
+--- uip/sortm.c	2000/02/04 20:28:24	1.3
++++ uip/sortm.c	2002/10/15 10:38:32
+@@ -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++;