Re: [PATCH v2 3/3] Use the newly-introduced regexec_buf() function
- From
Jeff King <peff@peff.net>
- Date
- Sep 8, 2016, 19:53 UTC
- Message-ID
- <20160908195300.votzp3ysxewc2mip@sigill.intra.peff.net>
- In-Reply-To
- <ac0f3441-d28f-fc5c-0273-f614b2cd4e07@ramsayjones.plus.com>
On Thu, Sep 08, 2016 at 08:06:35PM +0100, Ramsay Jones wrote:
Show 21 quoted lines
> > Actually, I take it back again. Your test case doesn't have an embedded
> > NUL in it (so we check that git finds it, but aside from the lack of
> > segfault, stock git would already find it).
>
> This reminds me ... despite the native cygwin regex library no longer
> having the 'regex bug' (ie t0070.5 now passes), I still have NO_REGEX
> set on cygwin. This is because, when building with the native library,
> we have an "unexpected pass" for t7008.12, which looks like:
>
> test_expect_failure 'git grep .fi a' '
> git grep .fi a
> '
> [where the file a is set up earlier by: echo 'binaryQfile' | q_to_nul >a]
>
> commit f96e5673 ("grep: use REG_STARTEND for all matching if available",
> 22-05-2010) introduced this test and expects ".. NUL characters themselves
> are not matched in any way". With the native library on cygwin they are
> matched, with the compat/regex they are not. Indeed, if you use the system
> 'grep' command (rather than 'git grep'), then it will also not match ... :-D
>
> Slightly off topic, but ...Hmm. So it sounds like the "regmatch" in grep.c could go away in favor of Johannes's regexec_buf(), and cygwin ought to be using NO_REGEX.
-Peff