[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'

>> 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.

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;
> +     }
>      }

reply via email to

[Prev in Thread] Current Thread [Next in Thread]