Path: utzoo!attcan!uunet!husc6!uwvax!dogie!uwmcsd1!ig!agate!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!ea.ecn.purdue.edu!davy
From: davy@ea.ecn.purdue.edu (Dave Curry)
Newsgroups: comp.mail.mh
Subject: Re: MH reply bug
Keywords: repl, mh
Message-ID: <3056@ea.ecn.purdue.edu>
Date: 13 May 88 21:30:49 GMT
References: <2846@dalcs.UUCP>
Reply-To: davy@ea.ecn.purdue.edu.UUCP (Dave Curry)
Organization: Purdue University Engineering Computer Network
Lines: 76

In article <2846@dalcs.UUCP> thompson@dalcs.UUCP (Michael Thompson) writes:
>
>    we have encountered an annoying bug in repl: if you try to reply to
>    a message that is not your current message then garbage gets
>    inserted at the end of your reply
[deleted]
>	If you can reproduce the bug and your system is different
>    please let me know.

It did it for me on Sun-3 (3.4) or Sun-4 (3.2) machines, and did it
whether you replied to the current message or any other one.  Since I
finally just upgraded to MH6.5 yesterday (so I procrastinated a little
bit...), I just now encountered this.

The following is what I sent to Bug-MH.  By the way, the document that
says "if you want to hack MH, my advice is don't" is quite correct...
it took me 3.5 hours to find this bug, and then 30 seconds to fix it.
Yuck.

-----
There is a bug in sbr/formatsbr.c in MH6.5 which causes extraneous
characters to appear after the headers in a "repl" or "forw" when on a
Sun machine.  The problem is due to alloc'ing a buffer exactly the
size of the components file and reading into it, with no terminating
null character.

Curiously, this is the same code that is in MH6.4 and we never had this
problem before.  Must be differences in where the compiler sticks its
data.  Ah well.

The following context diffs solve the problem.

--Dave Curry
Purdue University
Engineering Computer Network
davy@intrepid.ecn.purdue.edu

------------------------------ cut here ------------------------------
*** /tmp/,RCSt1a01291	Fri May 13 12:23:33 1988
--- formatsbr.c	Fri May 13 11:11:14 1988
***************
*** 47,53
  	if (fstat (fileno (fp), &st) == NOTOK)
  	    adios (form, "unable to stat format file");
  
! 	if ((formats = malloc ((unsigned) st.st_size)) == NULLCP)
  	    adios (form, "unable to allocate space for format");
  
  	if (read (fileno(fp), formats, st.st_size) != st.st_size)

--- 47,53 -----
  	if (fstat (fileno (fp), &st) == NOTOK)
  	    adios (form, "unable to stat format file");
  
! 	if ((formats = malloc ((unsigned) st.st_size + 1)) == NULLCP)
  	    adios (form, "unable to allocate space for format");
  
  	if (read (fileno(fp), formats, st.st_size) != st.st_size)
***************
*** 53,58
  	if (read (fileno(fp), formats, st.st_size) != st.st_size)
  	    adios (form, "error reading format file");
  
  	(void) fclose (fp);
      }
      else {

--- 53,59 -----
  	if (read (fileno(fp), formats, st.st_size) != st.st_size)
  	    adios (form, "error reading format file");
  
+ 	formats[(unsigned) st.st_size] = '\0';
  	(void) fclose (fp);
      }
      else {
------------------------------ cut here ------------------------------