From: Jonathan Nieder <jrnieder@gmail.com>
Date: Fri, 16 Jul 2010 21:06:09 GMT
Subject: Re: [PATCH] grep: Don't pass a TODO test if REG_STARTEND is supported
Message-ID: <20100716210609.GA23044@burratino>
In-Reply-To: <AANLkTikDwJaBN8Y0814m6JaVab9BAXPx_VKE7Z_Q6hq7@mail.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

> The failure is totally predicated on whether or not REG_STARTEND is
> available on the system
[...]
> Then you could do:
> 
>     test_expect_success REG_STARTEND 'git grep ile a' '
>         git grep ile a
>     '

Sorry to harp on this, but no, that would not be right.  When
REG_STARTEND is not available on a system, this is still a bug and
we still want to know when it is fixed.  The test should not be
skipped.

So one could do:

 if have_reg_startend
 then
	expectation=success
 else
	expectation=failure
 fi
 test_expect_$expectation 'git grep ile a' '
	git grep ile a
 '

> The glibc one is probably pretty good as far as minimal POSIX DFA
> engines go. Hopefully you can patch it up to get it to compile on
> non-GNU systems.

No promises, in particular because I don’t have any non-GNU
installations handy to test on.  Probably gnulib’s copy will do,
as Andreas suggested.

> Regarding regular expression implementations. We might want to look
> into bundling one implementation and using it everywhere

Please no. :)

If we can do better than glibc, then glibc should be improved (yes,
I know GNU grep does much better than glibc already).

> Using NFA engines like that also gives you some performance guarantees

Do you mean “using DFA engines”?  i.e. I thought GNU grep avoids
backtracking by converting the NFA to a DFA, at least conceptually.

Thanks for the food for thought,
Jonathan