Thread (7 messages) flat view 7 messages, 3 authors, 2016-06-15

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

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2016-06-15 22:49:08

On Fri, Jul 16, 2010 at 21:06, Jonathan Nieder [off-list ref] wrote:
Ævar Arnfjörð Bjarmason wrote:
quoted
The failure is totally predicated on whether or not REG_STARTEND is
available on the system
[...]
quoted
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 :)
quoted
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.
quoted
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.
quoted
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 :)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help