[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] tests: exercise two recently-fixed bugs
From: |
Jim Meyering |
Subject: |
Re: [PATCH] tests: exercise two recently-fixed bugs |
Date: |
Fri, 16 Mar 2012 22:50:22 +0100 |
Paul Eggert wrote:
>>> > I think we should give a "repeat count too large" error here. The regex
>>> > is being compiled to a different meaning than what the user intended.
>> Yes, definitely.
>> In testing, I noticed that we diagnose the range error
>> in the regexp path, but not in the DFA one, but haven't
>> gotten around to it. The DFA diagnostic should be the same
>> as the regexp one.
>
> Why? This isn't true of the other DFA diagnostics in 'grep'.
I consider grep's choice of when to use regex vs. DFA to be an
internal implementation detail, and as such think that its choice
should not have a significant effect on the output, other than
a presumed performance improvement when using the DFA matcher.
By contrast, perl silently wraps:
$ echo f|perl -nle '/f{4294967297}/ and print'
f
>> A patch would be most welcome.
>
> It turns out that the range error isn't diagnosed properly in
> the regexp path either. I pushed the following gnulib patch to
> fix this. I'll propose a grep patch shortly; it'll assume a
> sync from gnulib.
Thanks!
I haven't looked closely, but the TABs (maybe required in glibc?)
make the patch look bad.
...
> diff --git a/lib/regcomp.c b/lib/regcomp.c
> index e6d9c99..3841a0a 100644
> --- a/lib/regcomp.c
> +++ b/lib/regcomp.c
> @@ -2571,6 +2571,12 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp,
> re_dfa_t *dfa,
> *err = REG_BADBR;
> return NULL;
> }
> +
> + if (BE (RE_DUP_MAX < (end == REG_MISSING ? start : end), 0))
> + {
> + *err = REG_ESIZE;
> + return NULL;
> + }
> }