| Age | Commit message (Collapse) | Author |
|---|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines
(closes issue #13357)
Reported by: pj
Tested by: murf
(closes issue #13416)
Reported by: yarns
Tested by: murf
If you find this message overly verbose, relax, it's probably
not meant for you. This message is meant for probably only
two people in the whole world: me, or the poor schnook that
has to maintain this code because I'm either dead or unavailable
at the moment.
This fix solves two reports, both having to do with embedding
a function call in a ${} construct. It was tricky because the
funccall syntax has parenthesis () in it. And up till now,
the 'word' token in the flex stuff didn't allow that, because
it would tend to steal the LP and RP tokens. To be truthful,
the "word" token was the trickiest, most unstable thing in
the whole lexer. I was lucky it made this long without complaints.
I had to choose every character in the pattern with extreme
care, and I knew that someday I'd have to revisit it. Well,
the day has come.
So, my brilliant idea (and I'm being modest), was to use the
surrounding ${} construct to make a state machine and capture
everything in it, no matter what it contains. But, I have to now
treat the word token like I did with comments, in that I turn
the whole thing into a state-machine sort of spec, with new
contexts "curlystate", "wordstate", and "brackstate".
Wait a minute, "brackstate"? Yes, well, it didn't take very many
regression tests to point out if I do this for ${} constructs,
I also have to do it with the $[] constructs, too.
I had to create a separate pcbstack2 and pcbstack3 because
these constructs can occur inside macro argument lists, and
when we have two state machines operating on the same structures
we'd get problems otherwise. I guess I could have stopped at
pcbstack2 and had the brackstate stuff share it, but it doesn't
hurt to be safe. So, the pcbpush and pcbpop routines also now
have versions for "2" and "3".
I had to add the {KEYWORD} construct to the initial pattern for
"word", because previously word would match stuff like "default7",
because it was a longer match than the keyword "default". But,
not any more, because the word pattern only matches only one or
two characters now, and it will always lose. So, I made it the
winner again by making an optional match on any of the keywords
before it's normal pattern.
I added another regression test to make sure we don't
lose this in future edits, and had to fix just one regression,
where it no longer reports a 'cascaded' error, which I guess
is a plus.
I've given some thought as to whether to apply these fixes to
1.4 and the 1.6.x releases, vs trunk; I decided to put it in
1.4 because one of the bug reports was against 1.4; and it
is unexpected that AEL cannot handle this situation. It actually
reduced the amount of useless "cascade" error messages that
appeared in the regressions (by one line, ehhem). There is
a possible side-effect in that it does now do more careful
checking of what's in those ${} constructs, as far as matching
parens, and brackets are concerned. Some users may find a an
insidious problem and correct it this way. This should be
exceedingly rare, I hope.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
hi-order bit set. Not nice. Also, allow @ in extension names, and a backslash, also.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
after hitting the syntax error. An inspection of the code revealed that error tokens in lists were not rearranged when the rules were rearranged as part of a code neatening-up process. By moving the error tokens to where they should be, I also reduced the number of shift/reduce conflicts to 3 instead of 8. This introduces subtle differences in error messages, so the regressions had to be updated.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@80649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
redistributed/repartitioned to allow code re-use both inside and outside of Asterisk. This commit introduces the utils/conf2ael program, and an external config-file reader, for both normal config files, and for extensions.conf (context, exten, prio); It provides an API for programs outside of asterisk to use to play with the dialplan and config files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79255 | murf | 2007-08-13 11:49:54 -0600 (Mon, 13 Aug 2007) | 1 line
This patch fixes bug 10411. I added a new regression test, some regression test cleanups
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@57708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@44263 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
perform macro calls. This results in substantially smaller stack footprint, which allows macro call depths in excess of 100,000 levels, rather than the limit of 7 calls deep, which the Macro app is subject to.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@43747 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@39543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
option to aelparse.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@39430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
- fix callerid matching for extensions
- fix nested switch statements
- fix compilation with bison 2.1a or higher
(issue #7309)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@34665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
no longer considered experimental :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@22273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
