[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18762: [PATCH] dfa: don't consider RE_DOT_NEWLINE and RE_DOT_NOT_NUL
From: |
Jim Meyering |
Subject: |
bug#18762: [PATCH] dfa: don't consider RE_DOT_NEWLINE and RE_DOT_NOT_NULL in matching with a bracket expression |
Date: |
Sun, 19 Oct 2014 20:16:09 -0700 |
On Sun, Oct 19, 2014 at 6:24 PM, Jim Meyering <address@hidden> wrote:
> On Sat, Oct 18, 2014 at 7:07 PM, Norihiro Tanaka <address@hidden> wrote:
>> Jim Meyering <address@hidden> wrote:
>>> dfa.c's match_mb_charset function *is* used, e.g., in a
>>> command like this one:
>>>
>>> printf '\0' |src/grep -aE '^\s?$'
>>
>> Wow, just it isn't good. I think that behavior of `fails' should be
>> same as of `trans' except `fails' checks accepted conditions, including
>> following part. match_mb_charset() should be avoided as far as possible,
>> as it doesn't support collating symbols and equivalence classes.
>>
>>> /* Falling back to the glibc matcher in this case gives
>>> better performance (up to 25% better on [a-z], for
>>> example) and enables support for collating symbols and
>>> equivalence classes. */
>>> if (d->states[s].has_mbcset && backref)
>>> {
>>> *backref = 1;
>>> goto done;
>>> }
>
> Nice change. I've adjusted the commit log and added the test
> above, since no other code even excercised the
> now-inaccessible function. I will push it tomorrow.
By the way, I've also adjusted your preceding patch (see attached),
and will push it tomorrow, too.
0001-dfa-remove-two-erroneous-clauses-from-a-now-unused-f.patch
Description: Binary data