🚀 go-pugleaf

I recently stumbled upon an oversight in nnmaster that causes a coredump.

I couldn't get nnmaster to run in the background, so I kept doing a
complete rebuild of the database for nn.  But, nnmaster would never
finish.  I finally found out it was getting stuck in rec.music.synth.
Yep, I found a core file in there.  So, I recompiled nnmaster with the
-g switch so I could find the problem.  Turns out it was quitting with
IOT (signal 6).  (BTW, I am running on a 68010.  I thought IOT was only
for PDP machines...)  It was getting stuck in the pack_name routine in
pack_name.c.  I figured out what article it was processing, which is
posted below.  Look at the length of the From: line.  Looks like some
garbage crept in there.

Path: ivucsb!anise.acc.com!apple!usc!bbn!rochester!daemon
From: miller@CS.ROCHESTER.EDU, , bet@orion writes: >I got the PF-85 >	 TAKING A GOOD PAIR OF HEADPHONES WITH ME! If you care about >	 the sound, this step is crucial. Amp, spea (Brad Miller)
Newsgroups: rec.music.synth
Subject: Re: Shopping for a digitally synth. electronic piano
Message-ID: <1989Sep7.205538.10037@cs.rochester.edu>
Date: 7 Sep 89 20:55:38 GMT
Sender: daemon@cs.rochester.edu (Old Scratch)
Organization: University of Rochester Computer Science Department
Lines: 5

[msg deleted]

Anyway, the problem is in pack_name.c.  On line 174, we get a 129 character
namebuf.  Unfortunately, it looks like pack_name never checks to see if
the incoming name is longer than 128 characters!

Unfortunately, I can't make out exactly what the code is doing, so my
"bugfix" is simply to edit the message to make it more reasonable.  I'll
let someone who knows what they're doing come up with a fix.

-- 

Todd Day  |  todd@ivucsb.sba.ca.us  |  ivucsb!todd@anise.acc.com
"We live in an age where pizza gets to our house faster than the police."