From: pavenis AT lanet DOT lv To: "Eli Zaretskii" , 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: (message from Andris Pavenis on Sat, 8 Sep 2001 10:21:26 +0300 (WET)) X-mailer: Pegasus Mail for Win32 (v4.0, beta 40) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body 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 Precedence: bulk On 8 Sep 2001 at 13:20, Eli Zaretskii wrote: > > Date: Sat, 8 Sep 2001 10:21:26 +0300 (WET) > > From: Andris Pavenis > > 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 > }