[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):  trunk 
SVN Revision (number only!): 235811 
Request Review:              
====================================================================== 
Date Submitted:             2009-12-21 03:55 CST
Last Modified:              2009-12-22 22: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...
====================================================================== 

---------------------------------------------------------------------- 
 (0115704) tilghman (administrator) - 2009-12-22 22:28
 https://issues.asterisk.org/view.php?id=16482#c115704 
---------------------------------------------------------------------- 
(6) _2 and _[2] now compare as equal.  Previously, _2 would have sorted
before _[2] and would not have flagged an error as being equal.

Additionally, as to (3), I've removed the memset altogether, as the
structure can simply be initialized statically.  I've also restored the
original syntax, as I think it is more clear, and that code already suffers
from being a little difficult to read. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-22 22:28 tilghman       Note Added: 0115704                          
======================================================================