Date: Fri, 20 Jan 2017 19:28:10 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 209116] bsdgrep -Fxf failing if earlier non-match is a sub-prefix of the actual match Message-ID: <bug-209116-8-zTlcrKqDwc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209116-8@https.bugs.freebsd.org/bugzilla/> References: <bug-209116-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209116 Kyle Evans <bsdports@kyle-evans.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bsdports@kyle-evans.net --- Comment #1 from Kyle Evans <bsdports@kyle-evans.net> --- Created attachment 179160 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D179160&action= =3Dedit WIP patch for poor matching behavior Hi, So the way this works now, if I understand correctly, is it basically ends = up matching each successive pattern against a shorter and shorter subset of the string based on the last match that was made rather than comparing each pat= tern to the full length of the line that we're processing. This feels wrong, and indeed it ends up being wrong. I'm attaching a WIP patch for fixing this. It's still not quite right -- the 'nst' variable that I've added will generally advance the start of future matching to either the end of the line or the end of the last matched patte= rn, depending on how things work out. Do note that I've not yet checked any specifications on this to figure out whether it's expected that we would process again at the end of the shortest match or the end of the longest match, though intuition tells me we likely = want to start processing again at the end of the shortest match. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209116-8-zTlcrKqDwc>