aboutsummaryrefslogtreecommitdiffstats
path: root/main
diff options
context:
space:
mode:
authormurf <murf@f38db490-d61c-443f-a65b-d21fe96a405b>2008-03-27 21:28:22 +0000
committermurf <murf@f38db490-d61c-443f-a65b-d21fe96a405b>2008-03-27 21:28:22 +0000
commitb8bf6316445f933c962c21d3e63d0e9b2f5cf6e7 (patch)
tree6c6125b6591caefd03c271ed9a5e1557e691479a /main
parent91d03645d394edb89e6cf6c074ed5e3765de770e (diff)
Merged revisions 111497 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk ........ r111497 | murf | 2008-03-27 15:25:55 -0600 (Thu, 27 Mar 2008) | 1 line comment cleanup and iron out a really dumb mistake in handling the '.'-wildcard in the new exten pattern matcher. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@111498 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'main')
-rw-r--r--main/pbx.c19
1 files changed, 11 insertions, 8 deletions
diff --git a/main/pbx.c b/main/pbx.c
index 1ac737752..10a4776d8 100644
--- a/main/pbx.c
+++ b/main/pbx.c
@@ -74,14 +74,15 @@ ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
*
* A new algorithm to do searching based on a 'compiled' pattern tree is introduced
* here, and shows a fairly flat (constant) search time, even for over
- * 1000 patterns. Might Still needs some work-- there are some fine points of the matching
+ * 1000 patterns. Might Still need some work-- there are some fine points of the matching
* spec about tie-breaking based on the characters in character sets, but this
* should be do-able via the weight system currently being used.
*
* Also, using a hash table for context/priority name lookup can help prevent
- * the find_extension routines from absorbing exponential cpu cycles. I've tested
- * find_extension with red-black trees, which have O(log2(n)) speed. Right now,
- * I'm using hash tables, which do searches (ideally) in O(1) time.
+ * the find_extension routines from absorbing exponential cpu cycles as the number
+ * of extensions grow. I've previously tested find_extension with red-black trees,
+ * which have O(log2(n)) speed. Right now, I'm using hash tables, which do
+ * searches (ideally) in O(1) time.
*
*/
@@ -1025,10 +1026,11 @@ static void new_find_extension(const char *str, struct scoreboard *score, struct
/* how many chars will the . match against? */
int i = 0;
const char *str2 = str;
- while (*str2++) {
+ while (*str2 && *str2 != '/') {
+ str2++;
i++;
}
- if (p->exten && !(*(str+1)))
+ if (p->exten && *str2 != '/')
update_scoreboard(score, length+i, spec+(i*p->specificity), p->exten, '.', callerid, p->deleted, p);
if (p->next_char && p->next_char->x[0] == '/' && p->next_char->x[1] == 0) {
new_find_extension("/", score, p->next_char, length+i, spec+(p->specificity*i), callerid);
@@ -1038,10 +1040,11 @@ static void new_find_extension(const char *str, struct scoreboard *score, struct
/* how many chars will the . match against? */
int i = 0;
const char *str2 = str;
- while (*str2++) {
+ while (*str2 && *str2 != '/') {
+ str2++;
i++;
}
- if (p->exten && !(*(str+1)))
+ if (p->exten && *str2 != '/')
update_scoreboard(score, length+1, spec+(p->specificity*i), p->exten, '!', callerid, p->deleted, p);
if (p->next_char && p->next_char->x[0] == '/' && p->next_char->x[1] == 0) {
new_find_extension("/", score, p->next_char, length+i, spec+(p->specificity*i), callerid);