[asterisk-dev] [asterisk-commits] murf: trunk r89272 - /trunk/main/pbx.c

[Steve Murphy]

On Tue, 2007-11-20 at 23:55 -0800, Luigi Rizzo wrote:
> On Tue, Nov 20, 2007 at 07:29:08PM -0700, Steve Murphy wrote:
> > On Fri, 2007-11-16 at 09:35 -0800, Luigi Rizzo wrote:
> > > On Fri, Nov 16, 2007 at 10:07:54AM -0700, Steve Murphy wrote:
> > 
> > > > So, my system interprets this by assigning weights to each pattern char,
> > > > where, right now, N gets 98, Z gets 99, X gets 100, . and ! get 200 (per
> > > > char matched).
> > > > A sing char, non pattern, gets '1', and char ranges ( [0123] ), get a
> > > > count of the number of chars in the range, where the LOWEST score wins.
> > > 
> > > I don't understand why N Z X are 98 99 100 instead of 8 9 10 as the
> > > equivalent [2-9] [1-9] [0-9] ranges ?
> > > 
> > 
> > This is because, when notation is a mixture of literal chars, and char
> > ranges, that the raw totals don't always reflect what you would
> > intuitively think. If a pattern with CID match adds up to around 20
> > chars, to make the NZX notation stick out, use numbers near 100. That
> 
> it's not a matter of intuition or sticking out.
> 
> X and [0-9] and [0-345-9] and variants thereof are exactly the same
> pattern and must be dealt with in the same way (in fact, when i
> cleaned up the matching code some time ago i was very tempted to
> rewrite patterns in a canonical form (replacing X's with [0-9], and
> possibly replacing ranges with a 256-bit bitmap containing the exact
> list, so it could be scanned in constant time).
> 
> I am not saying that the rule for precedence of patterns is
> unchangable, but once you pick one rule, you must use it consistently
> across your code, or you end up opening more bugs than you fix.
> 
> Really, this is not an area where you can afford playing and putting in
> small patches to see how they fix one or the other problem.
> The correctness of extension matching is something that people
> really must rely on, because in the end it is directly involved
> with security, billing and so on.
> 
> I must really re-empasize my request to have the option to use the
> old code in trunk. Be it at compile time, 'extension load' time,
> or on the fly as it turns out to be more convenient, but this is
> really really necessary.

OK, Luigi--

I'm almost finished. I added a new config file option,
 "extenpatternmatchnew = true/false" 
to the [general] section of the extensions.conf. By default, it's
'false'.
The option to use the old or new algorithm is tested at run time and can
be switched on or off anytime. I'm adding a cli command to set it
true/false, so you switch over while asterisk is running. "dialplan
setnewmatch true/false"

It's not that hard. Had an idea this morning as I was waking up.

Will test it to make sure it all works right before I commit, tho.

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/20071122/4a256d28/attachment.bin