[asterisk-bugs] [Asterisk 0012777]: [patch] Pattern matching treats 'x' differently than 'X'

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12777 
====================================================================== 
Reported By:                jsmith
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12777
Category:                   PBX/pbx_config
Reproducibility:            always
Severity:                   minor
Priority:                   high
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 117582 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-02-2008 21:50 CDT
Last Modified:              06-02-2008 23:28 CDT
====================================================================== 
Summary:                    [patch] Pattern matching treats 'x' differently than
'X'
Description: 
Steve Edwards reported
[http://lists.digium.com/pipermail/asterisk-users/2008-June/212956.html]
that the pattern _2xxx is evaluated before _2[1-4]00.  I went to reply that
it shouldn't be that way, but in my testing, I found he was right.

I think this is a pretty serious bug in the pattern matching code.

As I understand it, Asterisk should be evaluating the patterns one digit
at a time, from left to right.  Whenever more than one pattern could
possibly match, the *most constrained* digit should match first.  In other
words, given these two patterns, if I dialed 1234, the first one should
match before the second, as it's a more constrained match in the third
digit (it matches two possible values, while the other matches three).

_12[3-4]X
_12[3-5]X

The problem arises in that Asterisk seems to be treating the wildcard 'X'
differently than 'x', and I can't figure out why.  Both of them should mean
"any digit 0 through 9", but apparently they don't.  See below for more
details:
====================================================================== 

---------------------------------------------------------------------- 
 jsmith - 06-02-08 23:28  
---------------------------------------------------------------------- 
Just to clarify... I think the two options should be:

1) treat a lower-case character (n, x, z) exactly the same as it's
upper-case counterpart (N, X, Z) or

2) treat a lower-case character (n, x, z) as a *literal* character

I *do not* think we should treat the lower-case characters as "special
ways of overriding the default matching order".  As for the other two
options I mentioned, the element of least surprise (and comments in the
source code, as well as being very familiar with the way people write
pattern matchines) leads me to lean *very strongly* towards option number
1. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-02-08 23:28  jsmith         Note Added: 0087695                          
======================================================================