11 Commits (9bcdef268432e7591142b1b8de38b2e7871566a5)

Author	SHA1	Message	Date
Sean Bright	acd1513111	ael: Regenerate lexers and parsers. ... Various changes to ensure that the lexers and parsers can be correctly generated when REBUILD_PARSERS is enabled. Some notes: * Because of the version of flex we are using to generate the lexers (2.5.35) some post-processing in the Makefile is still required. * The generated lexers do not contain the problematic C99 check that was being replaced by the call to sed in the respective Makefiles so it was removed. * Since these files are generated, they will include trailing whitespace in some places. This does not need to be corrected. Change-Id: Ibbd343606fcf5c0d285b1599e6e8e59f514f2e4e	3 years ago
Sean Bright	fd0ca1c3f9	Remove as much trailing whitespace as possible. ... Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0	8 years ago
Russell Bryant	cad07b3800	Multiple revisions 360356-360357 ... ........ r360356 | russell | 2012-03-23 22:33:36 -0400 (Fri, 23 Mar 2012) | 6 lines expression parser: Fix (theoretical) memory leak. Fix a memory leak that is very unlikely to actually happen. If a malloc() succeeded, but the following strdup() failed, the memory from the original malloc() would be leaked. ........ r360357 | russell | 2012-03-23 22:34:39 -0400 (Fri, 23 Mar 2012) | 6 lines Rebuild parsers. This is needed to include the last fix to main/ast_expr2.y. The changes look much bigger as this regeneration of the code was done with newer versions of flex and bison. ........ Merged revisions 360356-360357 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 360358 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360359 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Tilghman Lesher	d07eca63b6	Merged revisions 293197 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r293197 | tilghman | 2010-10-28 15:00:06 -0500 (Thu, 28 Oct 2010) | 33 lines Merged revisions 293195-293196 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r293195 | tilghman | 2010-10-28 14:52:52 -0500 (Thu, 28 Oct 2010) | 12 lines Merged revisions 293194 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r293194 | tilghman | 2010-10-28 14:44:37 -0500 (Thu, 28 Oct 2010) | 5 lines "!00" evaluated as false, which is incorrect. Fixing. Reported (though the reporter did not understand he was reporting a bug) on the asterisk-users list: http://lists.digium.com/pipermail/asterisk-users/2010-October/255505.html ........ ................ r293196 | tilghman | 2010-10-28 14:54:34 -0500 (Thu, 28 Oct 2010) | 12 lines Merged revisions 293194 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r293194 | tilghman | 2010-10-28 14:44:37 -0500 (Thu, 28 Oct 2010) | 5 lines "!00" evaluated as false, which is incorrect. Fixing. Reported (though the reporter did not understand he was reporting a bug) on the asterisk-users list: http://lists.digium.com/pipermail/asterisk-users/2010-October/255505.html ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293198 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Steve Murphy	068859119a	In these changes, I have added some explanation ... of changes to the Set and MSet apps, so people aren't so shocked and surprised when they upgrade from 1.4 to 1.6. Also, for the sake of those upgrading from 1.4 to 1.6 with AEL, I provide automatic support for the "old" way of using Set(), that still does the exact same old thing with quotes and backslashes and so on as 1.4 did, by having AEL compile in the use of MSet() instead of Set(), everywhere it inserts this code. But, if the app_set var is set to 1.6 or higher, it uses the "new", non-evaluative Set(). This only usually happens if the user manually inserts this into the asterisk.conf file, or runs the "make samples" command. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140824 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	d78f79d82c	Oops. put a decl in a generated file. My bad, but fixed now. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138845 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	04795d963f	These changes are in regards to bug 13249, where users are being surprised by the changes made ... to the Set app in trunk/1.6.x, as they come from the 1.4 world. They are only bitten if they write their AEL dialplan in the 1.4 world, and then carry it over to a trunk/1.6.x installation where a "make samples" was executed, or where they hand-edited the asterisk.conf file and added the [compat] category with app_set = 1.6 (or higher). (this commit does not totally solve 13249, at least not yet) The change involves issueing a single warning while the AEL file is loading, if: 1. app_set is present in the config file, and set to 1.6 or higher. 2. there are double quotes in an assignment statement (eg x = "hi there";) 3. the warning was not already issued. The standalone app, aelparse, does not (yet) issue this warning. I'd have to have it read in the asterisk.conf file, and that's a bit of hassle. I'll add it if users request it, tho. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138815 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	377e51c4d4	(closes issue #6002) ... Reported by: rizzo Tested by: murf Proposal of the changes to be made, and then an announcement of how they were accomplished: http://lists.digium.com/pipermail/asterisk-dev/2008-February/032065.html and: http://lists.digium.com/pipermail/asterisk-dev/2008-March/032124.html Here is a recap, file by file, of what I have done: pbx/pbx_config.c pbx/pbx_ael.c All funcs that were passed a ptr to the context list, now will ALSO be passed a hashtab ptr to the same set. Why? because (for the time being), the dialplan is stored in both, to facilitate a quick, low-cost move to hash-tables to speed up dialplan processing. If it was deemed necessary to pass the context LIST, well, it is just as necessary to have the TABLE available. This is because the list/table in question might not be the global one, but temporary ones we would use to stage the dialplan on, and then swap into the global position when things are ready. We now have one external function for apps to use, "ast_context_find_or_create()" instead of the pre-existing "find" and "create", as all existing usages used both in tandem anyway. pbx_config, and pbx_ael, will stage the reloaded dialplan into local lists and tables, and then call merge_contexts_and_delete, which will merge (now) existing contexts and priorities from other registrars into this local set by copying them. Then, merge_contexts_and_delete will lock down the contexts, swap the lists and tables, and unlock (real quick), and then destroy the old dialplan. chan_sip.c chan_iax.c chan_skinny.c All the channel drivers that would add regcontexts now use the ast_context_find_or_create now. chan_sip also includes a small fix to get rid of warnings about removing priorities that never got entered. apps/app_meetme.c apps/app_dial.c apps/app_queue.c All the apps that added a context/exten/priority were also modified to use ast_context_find_or_create instead. include/asterisk/pbx.h ast_context_create() is removed. Find_or_create_ is the new method. ast_context_find_or_create() interface gets the hashtab added. ast_merge_contexts_and_delete() gets the local hashtab arg added. ast_wrlock_contexts_version() is added so you can detect if someone else got a writelock between your readlocking and writelocking. ast_hashtab_compare_contexts was made public for use in pbx_config/pbx_ael ast_hashtab_hash_contexts was in like fashion make public. include/asterisk/pval.h ast_compile_ael2() interface changed to include the local hashtab table ptr. main/features.c For the sake of the parking context, we use ast_context_find_or_create(). main/pbx.c I changed all the "tree" names to "table" instead. That's because the original implementation was based on binary trees. (had a free library). Then I moved to hashtabs. Now, the names move forward too. refcount field added to contexts, so you can keep track of how many modules wanted this context to exist. Some log messages that are warnings were inflated from LOG_NOTICE to LOG_WARNING. Added some calls to ast_verb(3,...) for debug messages Lots of little mods to ast_context_remove_extension2, which is now excersized in ways it was not previously; one definite bug fixed. find_or_create was upgraded to handle both local lists/tables as well as the globals. context_merge() was added to do the per-context merging of the old/present contexts/extens/prios into the new/proposed local list/tables ast_merge_contexts_and_delete() was heavily modified. ast_add_extension2() was also upgraded to handle changes. the context_destroy() code was re-engineered to handle the new way of doing things, by exten/prio instead of by context. res/ael/pval.c res/ael/ael.tab.c res/ael/ael.tab.h res/ael/ael.y res/ael/ael_lex.c res/ael/ael.flex utils/ael_main.c utils/extconf.c utils/conf2ael.c utils/Makefile Had to change the interface to ast_compile_ael2(), to include the hashtab ptr. This ended up involving several external apps. The main gotcha was I had to include lock.h and hashtab.h in several places. As a side note, I tested this stuff pretty thoroughly, I replicated the problems originally reported by Luigi, and made triply sure that reloads worked, and everything worked thru "stop gracefully". I found a and fixed a few bugs as I was merging into trunk, that did not appear in my tests of bug6002. How's this for verbose commit messages? git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106757 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	c9f3efc381	Merged revisions 87168 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config, ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	83e28341b5	an unreported crash I debugged, looked like it was backing up way too far 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	18 years ago
Steve Murphy	9836efb5fb	This commit closes bug 7605, and half-closes 7638. The AEL code has been 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	18 years ago