[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170111100400.vhd5ytarqpujigbn@sigill.intra.peff.net>
Date: Wed, 11 Jan 2017 05:04:01 -0500
From: Jeff King <peff@...f.net>
To: git@...r.kernel.org
Cc: musl@...ts.openwall.com, Andreas Schwab <schwab@...ux-m68k.org>,
"A. Wilcox" <awilfox@...lielinux.org>
Subject: Re: Re: Test failures when Git is built with libpcre and grep
is built without it
On Tue, Jan 10, 2017 at 12:40:00PM +0100, Szabolcs Nagy wrote:
> > > 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.
> > > 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.
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
