Re: [PATCH 05/12] log: add exhaustive tests for pattern style options & config
- Date: Tue, 11 Apr 2017 06:51:31 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [PATCH 05/12] log: add exhaustive tests for pattern style options & config
On Tue, Apr 11, 2017 at 12:32:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > This can be tricky since POSIX allows implementations to add arbitrary
> > extensions for otherwise invalid syntax.
> For POSIX basic v.s. extended I'm relying on (|) not being
> metacharacters in basic but metachars needing quoting in extended. I
> very much doubt any regex implementation doesn't conform to that, but
> maybe some crazy implementation does...
Yeah, I think BRE vs ERE (vs fixed) is fine, because POSIX specifies the
differences. It's really PCRE, because ERE implementations have a
surprising amount of flexibility according to the standard (basically
anything invalid is listed as "undefined" and implementations are
allowed to do what they please).
> >> + if test_have_prereq LIBPCRE
> >> + then
> >> + git -c grep.patternType=perl log --pretty=tformat:%s \
> >> + --grep="\((?=1)" >actual.perl
> >> + fi &&
> > I'd have to double-check POSIX, but I suspect that it may allow (?=1) to
> > work in an ERE (since it's otherwise bogus to have "?" without a prior
> > element to match).
> Distinguishing PCRE from the rest is much easier, I'll add some more
> obscure PCRE feature to that which definitely doesn't exist in any
> POSIX rx library, e.g. (*COMMIT) or something.
I think (*) would be "undefined" by POSIX, and thus allowed for
extensions (though in practice it's probably fine). The "[\d]" trick was
the simplest one I could find that is reliably defined to be different
between ERE and PCRE.