On Mon, Jan 09, 2017 at 02:05:44PM +0100, Andreas Schwab wrote:
> On Jan 09 2017, "A. Wilcox" <awil...@adelielinux.org> wrote:
>
> > Interestingly enough, you seem to be right. The failure is very
> > bizarre and has nothing to do with system /bin/grep:
> >
> > test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
> > not ok 142 - grep -G -F -P -E pattern
> > #
> > # >empty &&
> > # test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c"
> > ab >actual &&
> > # test_cmp empty actual
> > #
> >
> > However:
> >
> > elaine trash directory.t7810-grep # git grep -G -F -P -E
> > a\x{2b}b\x{2a}c ab >actual
>
> You need to quote the regexp argument, see the line starting with
> "test_must_fail" above.
Oh, duh. I checked that the line in the test was quoted, and didn't
notice that only the unquoted version he ran later complained. Thanks
for noticing, as that explains the mystery, I think.
The problem is that we are expecting the regex "\x{2b}" to complain in
regcomp() (as an ERE), but it doesn't. And that probably _is_ related to
musl, which is providing the libc regex (I know this looks like a pcre
test, but it's checking that "-P -E" overrides the pcre option with
"-E").
I'm not sure if musl is wrong for failing to complain about a bogus
regex. Generally making something that would break into something that
works is an OK way to extend the standard. So our test is at fault for
assuming that the regex will fail. I guess we'd need to find some more
exotic syntax that pcre supports, but that ERE doesn't. Maybe "(?:)" or
something.
-Peff
