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

[Paolo Bonzini]

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.

Paolo