[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:                     acknowledged
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-21 18: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...
====================================================================== 

---------------------------------------------------------------------- 
 (0115620) wdoekes (reporter) - 2009-12-21 18:28
 https://issues.asterisk.org/view.php?id=16482#c115620 
---------------------------------------------------------------------- 
List of things I fixed:

(1) The old comment at the top of ext_cmp1 should have been removed.
(2) Moved the while() to a do()while as it only needed checking
    after the calls.
(3) Skipped past the underscores (unnecessary extra check).
(3) Moved the memset out of the ext_cmp1. This way it has to know
    less about the actual length of bitwise.
(4) "bitwise[ c1 / 8 ] & mask" was compared to 1 which fails unless
    mask is also 1. It should've been compared against mask (or just
    the truth value).
(5) Changed unsetting bits in the mask to setting bits so sort order
    works better ([2-4] before [246] makes more sense than the other
    way around). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-21 18:28 wdoekes        Note Added: 0115620                          
======================================================================