[asterisk-bugs] [Asterisk 0016482]: [patch] Serious problem with pattern matching (regression in #15421)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16482 
====================================================================== 
Reported By:                wdoekes
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16482
Category:                   PBX/pbx_config
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
JIRA:                       SWP-576 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 235811 
Request Review:              
====================================================================== 
Date Submitted:             2009-12-21 03:55 CST
Last Modified:              2009-12-23 01:28 CST
====================================================================== 
Summary:                    [patch] Serious problem with pattern matching
(regression in https://issues.asterisk.org/view.php?id=15421)
Description: 
Hi, with the following dialplan:

[context]
exten => _[23],1,Set(category=NL-normal)
exten => _[45],1,Set(category=NL-normal)
exten => _[67],1,Set(category=NL-normal)
exten => _[89],1,Set(category=NL-normal)
exten => _X,1,Set(category=NL-unknown) ; (catch all)

_X sorts above [23] since asterisk 1.6.1.10.

Look at the following outputs:


[Asterisk 1.6.1.9]

*CLI> dialplan show context
[ Context 'context' created by 'pbx_config' ]
  '_[23]' =>        1. Set(category=NL-normal)                   
[pbx_config]
  '_[45]' =>        1. Set(category=NL-normal)                   
[pbx_config]
  '_[67]' =>        1. Set(category=NL-normal)                   
[pbx_config]
  '_[89]' =>        1. Set(category=NL-normal)                   
[pbx_config]
  '_X' =>           1. Set(category=NL-unknown)                  
[pbx_config]

[Asterisk 1.6.1.10 and above, up to -svn]

*CLI> dialplan show context
[ Context 'context' created by 'pbx_config' ]
  '_[89]' =>        1. Set(category=NL-normal)                   
[pbx_config]
  '_X' =>           1. Set(category=NL-unknown)                  
[pbx_config]
  '_[67]' =>        1. Set(category=NL-normal)                   
[pbx_config]
  '_[45]' =>        1. Set(category=NL-normal)                   
[pbx_config]
  '_[23]' =>        1. Set(category=NL-normal)                   
[pbx_config]


In my real world case:
exten => _+31X!,2,Set(category=NL-unknown) ; (catch all)
sorts above:
exten => _+31[2357]XXXXXXXX,2,Set(category=NL-normal)
yielding NL-unknown for normal Dutch phone numbers.


As far as I can see, this bug was introduced by the patch applied to fix
https://issues.asterisk.org/view.php?id=15421. (It touches the ext_cmp stuff and
was introduced in 1.6.1.10.)

I'll try to come up with more detailed information. (But I've flagged it
as Major in the mean time as I believe it to be a serious issue.)


Regards,
Walter Doekes
OSSO B.V.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015421 [patch] Serious problem in pattern matc...
====================================================================== 

---------------------------------------------------------------------- 
 (0115708) tilghman (administrator) - 2009-12-23 01:28
 https://issues.asterisk.org/view.php?id=16482#c115708 
---------------------------------------------------------------------- 
Oops.  I was thinking about doing just that, but I dropped it, since it's
not backwards compatible with the current workings of released versions. 
We can reconsider that in trunk, however. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-23 01:28 tilghman       Note Added: 0115708                          
======================================================================