bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Norihiro Tanaka
Example, a+a+a 1 2 3 position 1 has a repetition of "a" and other transition with "a". position 2 has a repetition of "a" and other transition with "a", too. Then DFA was merging the two nodes, but it is wrong. Now similar nodes in series are not merged. From 88bad5597445650f4e1bca663a82d4e4

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread arnold
Norihiro Tanaka wrote: > Example, > > a+a+a > 1 2 3 > > position 1 has a repetition of "a" and other transition with "a". > position 2 has a repetition of "a" and other transition with "a", too. > Then DFA was merging the two nodes, but it is wrong. > > Now similar nodes in series are not mer

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Jim Meyering
On Sun, Nov 1, 2020 at 12:42 AM Norihiro Tanaka wrote: > Example, > > a+a+a > 1 2 3 > > position 1 has a repetition of "a" and other transition with "a". > position 2 has a repetition of "a" and other transition with "a", too. > Then DFA was merging the two nodes, but it is wrong. > > Now simi

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Jim Meyering
On Sun, Nov 1, 2020 at 7:19 AM Jim Meyering wrote: > > On Sun, Nov 1, 2020 at 12:42 AM Norihiro Tanaka wrote: > > Example, > > > > a+a+a > > 1 2 3 > > > > position 1 has a repetition of "a" and other transition with "a". > > position 2 has a repetition of "a" and other transition with "a", to

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Norihiro Tanaka
Hi, By the way, I was wondering whether to add the test to ere.tests or spencer1.tests or to a new file. How should they be used properly?

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Jim Meyering
On Sun, Nov 1, 2020 at 7:31 AM Norihiro Tanaka wrote: > Hi, > By the way, I was wondering whether to add the test to ere.tests or > spencer1.tests or to a new file. How should they be used properly? Adding the new test in either place is fine, but there should be a comment. Also, we need a NEWS

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Jim Meyering
On Sun, Nov 1, 2020 at 8:02 AM Jim Meyering wrote: > > On Sun, Nov 1, 2020 at 7:31 AM Norihiro Tanaka wrote: > > Hi, > > By the way, I was wondering whether to add the test to ere.tests or > > spencer1.tests or to a new file. How should they be used properly? > > Adding the new test in either pl

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Jim Meyering
On Sun, Nov 1, 2020 at 8:05 AM Jim Meyering wrote: > On Sun, Nov 1, 2020 at 8:02 AM Jim Meyering wrote: > > > > On Sun, Nov 1, 2020 at 7:31 AM Norihiro Tanaka wrote: > > > Hi, > > > By the way, I was wondering whether to add the test to ere.tests or > > > spencer1.tests or to a new file. How sh

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Paul Eggert
Thanks to all for the bug report and quick fix. Closing the bug report.

bug#44351: Bug in grep v3.2 onwards in regular expression matching

2020-11-01 Thread Jim Meyering
On Sun, Nov 1, 2020 at 10:03 AM Paul Eggert wrote: > Thanks to all for the bug report and quick fix. Closing the bug report. Thanks for closing that. I've pushed the gnulib changes and am about to push those for grep, too.

bug#43862: [PATCH] grep: set RE_NO_SUB for calling regex only to check syntax

2020-11-01 Thread Jim Meyering
On Mon, Oct 12, 2020 at 4:08 PM Jim Meyering wrote: > On Thu, Oct 8, 2020 at 2:41 AM Norihiro Tanaka wrote: > > > > We can set RE_NO_SUB for calling regex only to check syntax. It brings > > performance gains in cases to have a lot of enormous epsilon nodes. > > > > > > $ printf '(%02d)\n' |

bug#43862: [PATCH] grep: set RE_NO_SUB for calling regex only to check syntax

2020-11-01 Thread Norihiro Tanaka
On Sun, 1 Nov 2020 11:39:55 -0800 Jim Meyering wrote: > We must accept the fact that extreme regular expressions will cause > resource exhaustion like that when processed by classical regex_* > functions. This is yet another good reason to prefer PCRE and to use > grep's -P option. In that case