On Mon, Mar 11, 2013 at 02:18:51PM -0700, Steve Kargl wrote: > On Mon, Mar 11, 2013 at 10:05:47PM +0100, Dimitry Andric wrote: > > On 2013-03-11 20:00, Jan Beich wrote: > > > Dimitry Andric <dim_at_FreeBSD.org> writes: > > > > > >> $ echo 'sub/foo.barx' | grep sub/foo.bar > > >> $ echo $? > > >> 1 > > > > > > $ echo 'sub/foo.barx' | env -i grep sub/foo.bar > > > $ echo 'sub/foolbarx' | env -i grep sub/foo.bar > > > $ echo 'sub/foo.barx' | env -i grep 'sub/foo\.bar' > > > sub/foo.barx > > > $ echo 'sub/foo.barx' | env -i grep -o sub/foo.bar > > > sub/foo.bar > > > $ echo 'sub/foo.barx' | env -i grep --color=no sub/foo.bar > > > sub/foo.barx > > > > > > A buggy shortcut? > > > > No, after some digging in and debugging of the bsdgrep code, I > > found out it is a regression caused by r246917, which is a fix > > for "bin/175213: [patch] bsdgrep(1) segfaults upon malicious input". > > If you revert it, bsdgrep starts working correctly again. > > First, I can report that bootstrapping gcc-4.8.0 works if I use > gnugrep instead of bsdgrep. The above explains why I had previously > seen the failure as I was using an older bsdgrep. > > Second, an apology is owed to the clang gang as I attributed the > problem to clang as it showed up on my system after converted > everything over to clang. > > > I think it would be best to back out r246917 for now, until the > > regression can be fixed properly. Having bsdgrep crash is bad, > > but not returning any results while it should is even worse... > > I tend to agree with your assessment that r246817 should be > reverted, because I hit this issue in configure scripts and > there is a large amount of software that uses autotool for > configuration. Sorry about this, I will revert it and revisit the problem. I've been using bsdgrep by default for a while and somehow haven't run into this. -MarkReceived on Tue Mar 12 2013 - 18:11:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC