strange regexp behavior

David Bateman David.Bateman at motorola.com
Tue Sep 23 05:00:46 CDT 2008


Thomas Weber wrote:
> Am Dienstag, den 23.09.2008, 11:04 +0200 schrieb David Bateman:
>   
>> Thomas Weber wrote:
>>     
>>> On Thu, Sep 18, 2008 at 11:34:55AM +0200, David Bateman wrote:
>>>   
>>>       
>>>> Thomas Weber wrote:
>>>>     
>>>>         
>>>>> I'm currently discussing this with PCRE developers on their list,  
>>>>> http://lists.exim.org/lurker/message/20080915.202357.7f71f452.en.html
>>>>>
>>>>> I already learned that this innocent looking pattern is a bad citizen :)
>>>>>   
>>>>>       
>>>>>           
>>>> Ok, tell us what happens with this thread.
>>>>     
>>>>         
>>> Patch attached; I've included a user-visible warning, because Phil Hazel
>>> (pcre's author) suggested that a regexp triggering such a problem should
>>> be rephrased.
>>>
>>> Maybe calling OCTAVE_QUIT in the added while-loop would be sensible as
>>> well.
>>>
>>> Patch is against 3.0.2, I had trouble compiling current tip. 
>>>
>>> 	
>>>       
>> Looking at the patch it looks ok to me, however maybe
>>
>> while (matches == PCRE_ERROR_MATCHLIMIT)
>>   {
>>      pe.match_limit *= 10;
>>     matches = pcre_exec(re, &pe, buffer.c_str(),
>>      buffer.length(), idx,
>>      (idx ? PCRE_NOTBOL : 0),
>>      ovector, (subpatterns+1)*3);
>>    }
>>
>> should be written as
>>
>> #define PCRE_MATCHLIMIT_MAX 10
>>     
>
> Yes, that's definitely a good idea.
>
>   
>> int i = 0;
>> while (matches == PCRE_ERROR_MATCHLIMIT && i++ < PCRE_MATCHLIMIT_MAX)
>>   {
>>      pe.match_limit *= 10;
>>     matches = pcre_exec(re, &pe, buffer.c_str(),
>>      buffer.length(), idx,
>>      (idx ? PCRE_NOTBOL : 0),
>>      ovector, (subpatterns+1)*3);
>>    }
>>
>> to avoid a truly infinite recursion in the pattern string. The max limit 
>> might need adjusting.. What issues did you have copiling with the tip?
>>     
>
> Something with the lexer, I think. Maybe I was missing bison?
>
> 	Thomas
>
>
>   
Ok, then what about the attached changeset for 3.1.51+ based on your 
patch that

* Adds a call to OCTAVE_QUIT
* Adds the loop counter to terminate for truly infinitely recursive patterns
* Adds a test based on the previously failing code.

I compiled and tested this sucessfully with 3.1.51+ and suppose it will 
work for 3.0.2+ as well.

Cheers
David

-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch8573
Url: https://www-old.cae.wisc.edu/pipermail/help-octave/attachments/20080923/aeffa528/attachment.ksh 


More information about the Help-octave mailing list