From:	pavenis AT lanet DOT lv
To:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>, ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De,
	djgpp-workers AT delorie DOT com
Date:	Sat, 8 Sep 2001 16:29:50 +0300
MIME-Version:	1.0
Subject:	Re: Problem with sed3028b.zip
Message-ID:	<3B9A477E.5211.E49BA0@localhost>
In-reply-to:	<7263-Sat08Sep2001132012+0300-eliz@is.elta.co.il>
References:	<Pine DOT A41 DOT 4 DOT 05 DOT 10109081013060 DOT 53626-100000 AT ieva06> (message from Andris Pavenis on Sat, 8 Sep 2001 10:21:26 +0300 (WET))
X-mailer:	Pegasus Mail for Win32 (v4.0, beta 40)
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 8 Sep 2001 at 13:20, Eli Zaretskii wrote:

> > Date: Sat, 8 Sep 2001 10:21:26 +0300 (WET)
> > From: Andris Pavenis <pavenis AT lanet DOT lv>
> > Testing result ...^M
> > sedtest.in sedtest.out differ: char 8193, line 2731^M
> 
> It was a bug, allright; thanks for a simple test case.  I think the
> patch below fixes it; please try it.

Thanks

Tried together with second patch which makes sed much more fast
(I noticed that binary of sed-3.02.80 was very slow at my test but didn't mention that in my earlier e-mail).

My test passed Ok (this time under Win98SE). Didn't tried with configuring gcc as in this case I would 
need to get CR at exact 
position (I regenerated DJGPP source archive with some changes
after I got this problem)

Perhaps it would be nice to rerelease sed3028[bs].zip to avoid 
others getting the same problem (I had it already earlier, but didn't dig out then what was the reason)

Andris

> 
> --- sed/execute.c~1	Sat Jan  1 12:09:08 2000
> +++ sed/execute.c	Sat Sep  8 13:03:40 2001
> @@ -273,7 +273,11 @@ line_undosify(lbuf, from, ch)
>    size_t lbuf_len = lbuf->length;
>  
>    /* Remove character CH from the end of the line starting at offset FROM.  */
> -  if (lbuf_len > from && lbuf->text[lbuf_len-1] == ch)
> +  if ((lbuf_len > from
> +       /* This is for the case where CR was read in the previous call,
> +	  but its LF buddy was only read now.  */
> +       || (lbuf_len == from && ch == '\r'))
> +      && lbuf->text[lbuf_len-1] == ch)
>      lbuf->length--;
>  #endif
>  }

- Raw text -