bug#17248: [PATCH] grep: waste of a lot of memory for a large pattern in dfamust

Thanks, I installed that, and followed it up with the attached minor cleanup patch. >From 3e66a99da2d0fc06e28fa90f53d0d52d0d5f69f2 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 24 Apr 2014 09:40:34 -0700 Subject: [PATCH] dfa: minor tuneup of dfamust memory savings patch * src/dfa.c (al

bug#17136: [PATCH] dfa: speed up memory allocation, port to IRIX

Thanks for fixing that bug, which I introduced. I added the attached change to fix the comment (which I also wrote) that led me astray. >From 59f3fac48e8b5456f4e0a45dfd99fba38d8b7af5 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 24 Apr 2014 12:49:58 -0700 Subject: [PATCH] dfa: fix incorr

bug#17136: [PATCH] dfa: speed up memory allocation, port to IRIX

Jim Meyering wrote: The attached patch reenables those that do not elicit a warning from gcc-4.9. Thanks, with an unusual configuration I ran into another warning from GCC 4.9.0 and installed the attached followup patch. From f72c43c606b219204004ccdb327c7320f9106ce7 Mon Sep 17 00:00:00 2001

bug#16586: bug#17245: GREP BUG: grep -P and binary files

On Wed, Apr 23, 2014 at 10:39 PM, Paul Eggert wrote: > Jim Meyering wrote: >> >> anyone using grep -P to search data that is even a tiny bit >> inconsistent with their UTF-8 locale will now get an exit status of >> 2 rather than the matches they used to get. > > > Yes, I don't like that either, bu

bug#17336: [PATCH] grep: warning to be uninitialized with -Wall

If `lint' macro isn't defined, kwset.c is warned to be uninitialized with -Wall. Of course, even if it's warned, there is no operational problems. However, I can't find any reasons that `accept' variable should be uninitialized. So fix it. Norihiro From 97d42eacfe9d6682f90fbf6e2223e30413462a8a

bug#17136: [PATCH] dfa: speed up memory allocation, port to IRIX

On Thu, Apr 17, 2014 at 10:59 PM, Paul Eggert wrote: > I merged that patch into the grep trunk and am closing this bug report. > While merging, I removed one part of the patch that had a small but > measurable performance degradation, namely, the introduction of struct > dfatab. I found some othe

bug#17341: memory leak in dfa.c

Hi. Thanks to valgrind, I tracked down this memory leak in dfa.c. dfasuperset() when it does dfafree(sup) doesn't free(sup). Here's the fix. Thanks, Arnold --- diff --git a/src/dfa.c b/src/dfa.c index 8fc3d6f..9106814 100644 --- a/src/dfa.c +++ b/src/dfa.c @@ -3533,7 +3533,1

bug#17229: [PATCH 2/2] grep: speed-up by using memchr() in Boyer-Moore searching

Paul Eggert wrote: > Unfortunately it doesn't help for me; it causes the same benchmark to > take about 4.3s real-time. Here, I am talking about the version > resulting from applying the patch in > > to the mas

bug#17306: grep: skip checking of multibyte character boundary, reaching at eolbyte

Norihiro Tanaka wrote: In dfaexec(), if reaches at eolbyte, we can skip checking of multibyte character boundary. So then process mbp until here. Thanks, I installed that. The "mbp = p" assignment can be done unconditionally. Some of the other code in the neighborhood can stand some minor

bug#16871: problems about matching newline (with -z)

Stephane Chazelas wrote: The doc has a confusing statement ... Same confusion in tests/pcre: Thanks, I installed the attached patch to fix those. We can match a newline with grep -zP 'a\nb' (or '\x0a' or '\012' or '[\n]'...) but not easily without -P. Same for NUL characters. Yes, that's a

bug#17336: [PATCH] grep: warning to be uninitialized with -Wall

Norihiro Tanaka wrote: I can't find any reasons that `accept' variable should be uninitialized. Two reasons. First, if we add initialization to the source, that might cause some compilers to generate less-efficient code. More important, adding initialization might cause some human readers o

bug#17341: memory leak in dfa.c

Thanks, I merged that into the master version.