Re: [PATCH] grep: Don't pass a TODO test if REG_STARTEND is supported

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Jul 16, 2010 at 21:06, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Æ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
>  '

Well, the assumption I was making that we would do something in the
make or ./configure process to set NO_REGEX=YesPlease if we found that
the system didn't support REG_STARTEND, and fail loudly if that
requirenment wasn't met.

However, what you posted above would be what we'd want if we wanted a
soft requirement. Maybe that's what we want, I don't know :)

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

Probably, I didn't look closely at it.

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

I think engines like GNU grep get some of their speed by not
supporting some POSIX features. So it's not something you can
completely solve at the libc level, since regcomp/regexec should only
have POSIX semantics.

But I should find out if we need this before we discuss this any
further, if it's a big performance win when e.g. grep-ing through the
entire history of Linux it might be worth it.

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

Yes, I always mix up my NFA and DFA at this time of night. I should
just start writing whatever I think I don't mean, and that'll be what
I mean :)