Jim Meyering wrote:
> On Tue, Apr 19, 2016 at 9:04 AM, Paul Eggert wrote:
> > On 04/18/2016 08:05 AM, Paul Eggert wrote:
> >>
> >> 'm afraid someone with access to MirBSD will need to debug it.
> >
> > On second thought there is a simpler fix: stop using btowc. I installed the
> > attached patch
On 04/20/2016 01:49 AM, arn...@skeeve.com wrote:
This will likely mean interface additions in dfa.h and some minor
code changes in dfa.c.
One thing that bugged me about dfa.c (when I was looking at this
yesterday) is that it maintains some state in static variables, which
means it can't be us
This sped up 'seq 100 | grep . >/dev/null' by a factor of
380,000 on my platform (Fedora 23, x86-64, AMD Phenom II X4 910e,
en_US.UTF-8 locale).
* NEWS: Document this.
* src/grep.c (grepbuf): exit_on_match no longer implies that -q
was specified, so when a match is found, exit with exit_fai
On 04/21/16 02:10, Paul Eggert wrote:
On 04/20/2016 01:49 AM, arn...@skeeve.com wrote:
This will likely mean interface additions in dfa.h and some minor
code changes in dfa.c.
One thing that bugged me about dfa.c (when I was looking at this yesterday) is
that it maintains some state in static
I'm attaching a revised patch, relative to the latest grep, to implement the
idea of the Bug#18777 patch. This revision calls the new array "never_trail"
instead of "always_character_boundary" to nail down the concept a bit more
precisely. It also removes what appears to be an unnecessary p < mb
Paul Eggert wrote:
> This sped up 'seq 100 | grep . >/dev/null' by a factor of
> 380,000 on my platform (Fedora 23, x86-64, AMD Phenom II X4 910e,
> en_US.UTF-8 locale).
> + else if (S_ISCHR (tmp_stat.st_mode))
> +{
> + struct stat null_stat;
> + if (stat ("
On Wed, Apr 20, 2016 at 11:21 PM, Paul Eggert wrote:
> I'm attaching a revised patch, relative to the latest grep, to implement the
> idea of the Bug#18777 patch. This revision calls the new array "never_trail"
> instead of "always_character_boundary" to nail down the concept a bit more
> precisel
arn...@skeeve.com wrote:
Testing for same inode is likely to work but not guaranteed. I think
it'd be better to compare the major and minor device numbers on the two
stat buffers. If they're equal then you know for sure you have a null
device in hand.
I considered that, but major and minor devi
In updating Bug#18000's patches to the current grep source, I couldn't build
with just the first patch installed, so I squashed the first two patches into
one. Also, I changed a few more 'int's into 'bool's and fixed a comment or two.
The result is attached. Again, I'm not installing this yet, a
