diff options
author | murf <murf@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-03-27 21:28:22 +0000 |
---|---|---|
committer | murf <murf@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-03-27 21:28:22 +0000 |
commit | b8bf6316445f933c962c21d3e63d0e9b2f5cf6e7 (patch) | |
tree | 6c6125b6591caefd03c271ed9a5e1557e691479a /main | |
parent | 91d03645d394edb89e6cf6c074ed5e3765de770e (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.c | 19 |
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); |