Re: [PATCH] tests: exercise two recently-fixed bugs

[Jim Meyering]

Paolo Bonzini wrote:

> Il 16/03/2012 13:04, Paolo Bonzini ha scritto:
>> Il 16/03/2012 09:44, Jim Meyering ha scritto:
>>>>>>> +xp1=4294967297 # 2^32+1
>>>>>>> +xp2=4294967298 # 2^32+2
>>>>>>> +
>>>>>>> +fail=0
>>>>>>> +
>>>>>>> +# Before grep-2.11, when DFA-matching, a repetition count exceeding the
>>>>>>> +# range of "unsigned int" would silently wrap around.   Hence, 2^32+1
>>>>>>> +# would be treated just like "1", and both of these would
>>>>>>> mistakenly match.
>>>>>>> +
>>>>>>> +echo abc  | grep -E "b{$xp1}"   > out 2>&1; test $? = 1 || fail=1
>>>>>>> +compare out /dev/null || fail=1
>>>>>>> +echo abbc | grep -E "b{1,$xp2}" > out 2>&1; test $? = 1 || fail=1
>>>>>>> +compare out /dev/null || fail=1
>>> ...
>>>>>
>>>>> Should this be marked as expensive?
>>> Hi Paolo,
>>>
>>> Why?
>>> That test takes only a small fraction of a second.
>>> If it's slow for you, then there must be a bug.
>>> Or maybe you mean some other test?
>>
>> Based on the code it should have been awfully expensive.  I'll take a look.
>>
>> Paolo
>>
>>
>
> Ah, ok, I missed this:
>
>                         if (RE_DUP_MAX < hi)
>                           goto normal_char;
>
> which has this interesting result:
>
> $ echo 'b{1000000000}' | grep -E '^b{1000000000}$'
> b{1000000000}
>
> 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.

A patch would be most welcome.