On Sat, Oct 25, 2014 at 4:11 PM, Paul Eggert <egg...@cs.ucla.edu> wrote: > I'm getting a failure in pcre-invalid-utf8-input both before and after the > change, with CentOS 6.5 and pcre-7.8-6.el6.x86_64. In my case the failures > are segmentation violations; perhaps 7.8-4 has a different failure mode, or > perhaps there's some other minor change to your platform that causes libpcre > to infloop. Either way, this appears to be a PCRE bug that grep can't be > expected to work around. > > Does the attached patch cause the test to fail reliably for you, instead of > looping?
Yes. And a timeout of 3s should be fine. Thanks. Please push that. I've just built grep against the latest pcre from git (an Oct 10 commit with this hash: cc48a55a5de9c2103f6657147149bcf63ff61579), and then all of grep's tests pass. Ideally, we would detect and warn about inadequate versions of pcre, but that certainly need not block the release. > By the way, I'm not sure why tests distinguish between > require_en_utf8_locale_ and require_compiled_in_MB_support; the latter > requires the former, and there's no point requiring the former unless we > also require the latter. It looks like I added the require_compiled_in_MB_support function in grep commit v2.9-27-g46e5cc6, yet never realized that it subsumed require_en_utf8_locale_. You're welcome to clean up after the release.
