[asterisk-bugs] [Asterisk 0014076]: Extensions configuration is not being sorted correctly

[Asterisk Bug Tracker]

The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=14076 
====================================================================== 
Reported By:                toc
Assigned To:                blitzrage
====================================================================== 
Project:                    Asterisk
Issue ID:                   14076
Category:                   Core/PBX
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           1.6.0 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-12-15 06:53 CST
Last Modified:              2008-12-16 09:01 CST
====================================================================== 
Summary:                    Extensions configuration is not being sorted
correctly
Description: 
The matching performed on extensions.conf is not sorting the items as
expected.

Take this example:

[test-ext]
exten => _.,1,NoOp(Match 1)
exten => s-Nothing,1,NoOp(Match 3)
exten => _s.,1,NoOp(Match 2)
exten => _s-.,1,NoOp(Match 4)

The result of:
[test-ext]
exten => _.,1,NoOp(Match 1)
exten => s-Nothing,1,NoOp(Match 3)
exten => _s.,1,NoOp(Match 2)
exten => _s-.,1,NoOp(Match 4)

Is:
— Executing [s-Test at test-ext:1] NoOp("Local/s-Test at test-ext-0cbc;2",
"Match 2") in new stack

I would expect the match to occur on Match 4, this is the closed match
based on the number of items to match on.

Swap them around:
[test-ext]
exten => _.,1,NoOp(Match 1)
exten => s-Nothing,1,NoOp(Match 3)
exten => _s-.,1,NoOp(Match 4)
exten => _s.,1,NoOp(Match 2)

And this is the output:
— Executing [s-Test at test-ext:1] NoOp("Local/s-Test at test-ext-5f64;2",
"Match 4") in new stack

It appears to be inconsistent in applying the matching as I would expect
regardless of entry position, the same results to occur due to the
matching.
====================================================================== 

---------------------------------------------------------------------- 
 (0096442) murf (administrator) - 2008-12-16 09:01
 http://bugs.digium.com/view.php?id=14076#c96442 
---------------------------------------------------------------------- 
The pattern matcher, since about 2.5 years ago, and according to matching
rules
hashed out at a previous astridevcon, iirc (it was before *my* time), has
the stipulation that spaces and dashes in patterns be ignored.

Thus, _s-.  and _s.  are equivalent, and the first one will win, and the
second
will be interpreted as a duplicate and be tossed out.

This explains the Match 2/4 difference.

This behavior is pretty clearly explained in the code, but it doesn't say
why. I'll add a little verbage to pbx.c to explain this.

Personally, I'd not have put this sort of thing into the code. Sure, it
makes it so you can directly feed stuff like NXX-XXX-XXXX into patterns
and have them match 30789188888 into such a pattern but... the cost is
that such small, not-often-mentioned exceptions confuse users and earn
us bug reports. I've been working a lot on the dialplan code and I hadn't
noticed this till now, either! But I can't just remove it, as there may
be thousands of installations that depend on this behavior. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-16 09:01 murf           Note Added: 0096442                          
2008-12-16 09:01 murf           Status                   assigned => closed  
======================================================================