[asterisk-dev] [design] Matching algorithm

[Steve Murphy]

On Tue, 2008-06-03 at 10:34 -0500, Tilghman Lesher wrote:
> There is a bug that has been filed, number 12777, which describes a possible
> bug in the current matching algorithm.  I say possible, because it could also
> be seen as a feature.
> 
> Historically, in 1.2 and previous versions, the pattern matching was done
> based upon ASCII sorting.  That is, "_1" sorted before "_X", so "_1" matched
> before "_X".  This broke down from what people expected when you take into
> account class-based matching, such as "_[1-4]".  Since "X" occurs earlier in
> the ASCII table than "[", "_X" matched before "_[1-4]".
> 
> This was changed in 1.4, such that each class matched as if it were a single
> entity and more specific matches matched first.  So the last example reversed
> the sorting priority order, "_[1-4]" now matches before "_X".
> 
> In the matching code, however, there is an anomaly, in that if you use the
> lowercase versions of the common classes, that is "n", "x", and "z", they
> currently match earlier than more specific matches.  That is, "_x" matches
> before "_[1-4]", which matches before "_X".
> 
> Now, we are not going to change this behavior in 1.4, certainly.  That has the
> potential to break currently working dialplans, and where we can reasonably
> foresee such an outcome, we'd like to avoid that.
> 
> However, this is certainly an unintended behavior, and the question then
> becomes, do we document this as a way to override the pattern match
> algorithm, or do we change the lowercase class letters to behave the same
> as the uppercase class letters?
> 
> I open the floor to more discussion.

I thought I'd weigh in on this, as I've done a share of pattern matching
hacking.

IIrc, I'm pretty sure my fast pattern matcher does a pass over the
string and
upcases all the NXZ's. This is in trunk and 1.6.0 at the moment. If you
guys
decide that lowercase is not a matching pattern, this will have
ramifications on *that* code, and I'll have to mod it to duplicate the
old behavior. 

I'm willing to abide by whatever's decided, tho. It's a pretty minor
tweak to the code. (I believe/think/hope)

murf



-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080603/9f64c184/attachment.bin