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. -- SteveReceived on Mon Mar 11 2013 - 20:18:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC