Date: Fri, 07 Sep 2001 17:41:55 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Message-Id: <6480-Fri07Sep2001174153+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com
In-reply-to: <6745033395E@HRZ1.hrz.tu-darmstadt.de>
	(ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De)
Subject: Re: Problem with sed3028b.zip
References:  <6745033395E AT HRZ1 DOT hrz DOT tu-darmstadt DOT de>
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

> From: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
> Date: Fri, 7 Sep 2001 14:43:28 +0200
> 
> Only FYI: I have used the following very naive test file:
> 
> bar\
> foo\
> bar
> 
> and run the sed command:
> 
> "s/bar/rab/;s/foo/oof/"
> 
> I have inspected the produced file with a hex-editor. The file
> is completely ok. Especially, all backslashes are followed *only*
> by CR LF. This is independent of the EOL used in the source file.

The code I wrote to remove CRs only if followed by an LF might have
some obscure bug, that only raises its ugly head in some rare
situation, like when the CR character is the last one in the buffer
(and Sed needs to look ahead to see if there's an LF after it).  The
logic there is pretty tricky.  I will take another look, but don't
hold your breath: I usually don't find obscure bugs by just looking at
the code.  So I agree a small test case that reproduces this would be
useful: there's nothing like GDB to find such bugs.

Also, this might not be a bug in Sed, but rather something caused by
another utility (e.g., `tr'), which the new Sed exposes, since it
doesn't remove lone CR characters, like the older ports did.