Re: [musl] Re: Test failures when Git is built with libpcre and grep is built without it
- From
- Szabolcs Nagy <nsz@port70.net>
- Date
- Jan 10, 2017, 11:40 UTC
- Message-ID
- <20170110113959.GL17692@port70.net>
- In-Reply-To
- <5874B942.7070402@adelielinux.org>
* A. Wilcox <awilfox@adelielinux.org> [2017-01-10 04:36:50 -0600]:
Show 11 quoted lines
> On 09/01/17 15:33, Jeff King wrote:
> > 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\x is undefined in posix and musl is based on tre which supports \x{hexdigits} in ere.
(i think some bsd platforms use tre as libc regex so i'm surprised musl is the first to run into this.)
> > we'd need to find some more exotic syntax that pcre supports, but > > that ERE doesn't. Maybe "(?:)" or something.
i think you would have to use something that's invalid in posix ere, ? after empty expression is undefined, not an error so "(?:)" is a valid ere extension.
since most syntax is either defined or undefined in ere instead of being invalid, distinguishing pcre using syntax is not easy.
there are semantic differences in subexpression matching: leftmost match has higher priority in pcre, longest match has higher priority in ere.
$ echo ab | grep -o -E '(a|ab)' ab $ echo ab | grep -o -P '(a|ab)' a
unfortunately grep -o is not portable.