Re: [musl] Re: Test failures when Git is built with libpcre and grep is built without it

From: Jeff King <peff@peff.net>
Date: Jan 11, 2017, 10:04 UTC
Message-ID: <20170111100400.vhd5ytarqpujigbn@sigill.intra.peff.net>
In-Reply-To: <20170110113959.GL17692@port70.net>

On Tue, Jan 10, 2017 at 12:40:00PM +0100, Szabolcs Nagy wrote:

Show 7 quoted lines

> > > 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.

Thanks for confirming; I figured it was something like that.

Show 6 quoted lines

> > > 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.

Reading through POSIX[1], hardly anything is explicitly labeled as "invalid". Most things are just "undefined", which leaves rooms for implementations to do what they like.

That's a good thing for a standard to do, but a bad thing when you are trying to find behavior that differs reliably between PCRE and ERE. :) In most cases, PCRE constructs could be viable extensions to ERE.

Show 14 quoted lines

> 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.

In this case we're testing whether Git has internally fed the regex to pcre or to regcomp(), not a system grep. So we'd need something like "-o" for "git grep", which I don't think exists.

Another difference I found is that "[\d]" matches a literal "\" or "d" in ERE, but behaves like "[0-9]" in PCRE. I'll work up a patch based on that.

Thanks for your answer. I'll drop the musl list from the cc when I follow-up, as this is most definitely not a musl problem, but a git one.

-Peff