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
2008-08-19 15:59:12 +00:00
/* A Bison parser, made by GNU Bison 2.3. */
2006-04-24 17:41:27 +00:00
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
2008-08-19 15:59:12 +00:00
/* Skeleton implementation for Bison's Yacc-like parsers in C
Copyright ( C ) 1984 , 1989 , 1990 , 2000 , 2001 , 2002 , 2003 , 2004 , 2005 , 2006
Free Software Foundation , Inc .
2006-04-24 17:41:27 +00:00
This program is free software ; you can redistribute it and / or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation ; either version 2 , or ( at your option )
any later version .
This program is distributed in the hope that it will be useful ,
but WITHOUT ANY WARRANTY ; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
GNU General Public License for more details .
You should have received a copy of the GNU General Public License
along with this program ; if not , write to the Free Software
Foundation , Inc . , 51 Franklin Street , Fifth Floor ,
Boston , MA 02110 - 1301 , USA . */
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
2008-08-19 15:59:12 +00:00
/* As a special exception, you may create a larger work that contains
part or all of the Bison parser skeleton and distribute that work
under terms of your choice , so long as that work isn ' t itself a
parser generator using the skeleton or a modified version thereof
as a parser skeleton . Alternatively , if you modify or redistribute
the parser skeleton itself , you may ( at your option ) remove this
special exception , which will cause the skeleton and the resulting
Bison output files to be licensed under the GNU General Public
License without this special exception .
This special exception was added by the Free Software Foundation in
version 2.2 of Bison . */
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
/* C LALR(1) parser skeleton written by Richard Stallman, by
simplifying the original so - called " semantic " parser . */
2006-04-24 17:41:27 +00:00
/* All symbols defined below should begin with yy or YY, to avoid
infringing on user name space . This should be done even for local
variables , as they might otherwise be expanded by user macros .
There are some unavoidable exceptions within include files to
define necessary library symbols ; they are noted " INFRINGES ON
USER NAME SPACE " below. */
/* Identify Bison output. */
# define YYBISON 1
/* Bison version. */
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
2008-08-19 15:59:12 +00:00
# define YYBISON_VERSION "2.3"
2006-04-24 17:41:27 +00:00
/* Skeleton name. */
# define YYSKELETON_NAME "yacc.c"
/* Pure parsers. */
# define YYPURE 1
/* Using locations. */
# define YYLSP_NEEDED 1
/* Substitute the variable and function names. */
# define yyparse ael_yyparse
# define yylex ael_yylex
# define yyerror ael_yyerror
# define yylval ael_yylval
# define yychar ael_yychar
# define yydebug ael_yydebug
# define yynerrs ael_yynerrs
# define yylloc ael_yylloc
/* Tokens. */
# ifndef YYTOKENTYPE
# define YYTOKENTYPE
/* Put the tokens into the symbol table, so that GDB and other debuggers
know about them . */
enum yytokentype {
KW_CONTEXT = 258 ,
LC = 259 ,
RC = 260 ,
LP = 261 ,
RP = 262 ,
SEMI = 263 ,
EQ = 264 ,
COMMA = 265 ,
COLON = 266 ,
AMPER = 267 ,
BAR = 268 ,
AT = 269 ,
KW_MACRO = 270 ,
KW_GLOBALS = 271 ,
KW_IGNOREPAT = 272 ,
KW_SWITCH = 273 ,
KW_IF = 274 ,
KW_IFTIME = 275 ,
KW_ELSE = 276 ,
KW_RANDOM = 277 ,
KW_ABSTRACT = 278 ,
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
2007-10-26 17:39:39 +00:00
KW_EXTEND = 279 ,
EXTENMARK = 280 ,
KW_GOTO = 281 ,
KW_JUMP = 282 ,
KW_RETURN = 283 ,
KW_BREAK = 284 ,
KW_CONTINUE = 285 ,
KW_REGEXTEN = 286 ,
KW_HINT = 287 ,
KW_FOR = 288 ,
KW_WHILE = 289 ,
KW_CASE = 290 ,
KW_PATTERN = 291 ,
KW_DEFAULT = 292 ,
KW_CATCH = 293 ,
KW_SWITCHES = 294 ,
KW_ESWITCHES = 295 ,
KW_INCLUDES = 296 ,
KW_LOCAL = 297 ,
word = 298
2006-04-24 17:41:27 +00:00
} ;
# endif
/* Tokens. */
# define KW_CONTEXT 258
# define LC 259
# define RC 260
# define LP 261
# define RP 262
# define SEMI 263
# define EQ 264
# define COMMA 265
# define COLON 266
# define AMPER 267
# define BAR 268
# define AT 269
# define KW_MACRO 270
# define KW_GLOBALS 271
# define KW_IGNOREPAT 272
# define KW_SWITCH 273
# define KW_IF 274
# define KW_IFTIME 275
# define KW_ELSE 276
# define KW_RANDOM 277
# define KW_ABSTRACT 278
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
2007-10-26 17:39:39 +00:00
# define KW_EXTEND 279
# define EXTENMARK 280
# define KW_GOTO 281
# define KW_JUMP 282
# define KW_RETURN 283
# define KW_BREAK 284
# define KW_CONTINUE 285
# define KW_REGEXTEN 286
# define KW_HINT 287
# define KW_FOR 288
# define KW_WHILE 289
# define KW_CASE 290
# define KW_PATTERN 291
# define KW_DEFAULT 292
# define KW_CATCH 293
# define KW_SWITCHES 294
# define KW_ESWITCHES 295
# define KW_INCLUDES 296
# define KW_LOCAL 297
# define word 298
2006-04-24 17:41:27 +00:00
/* Copy the first part of user declarations. */
# line 1 "ael.y"
/*
2006-04-26 18:43:29 +00:00
* Asterisk - - An open source telephony toolkit .
2006-04-24 17:41:27 +00:00
*
* Copyright ( C ) 2006 , Digium , Inc .
*
* Steve Murphy < murf @ parsetree . com >
*
* See http : //www.asterisk.org for more information about
* the Asterisk project . Please do not directly contact
* any of the maintainers of this project for assistance ;
* the project provides a web site , mailing lists and IRC
* channels for your use .
*
* This program is free software , distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree .
*/
/*! \file
*
* \ brief Bison Grammar description of AEL2 .
2006-04-26 18:43:29 +00:00
*
2006-04-24 17:41:27 +00:00
*/
2006-07-19 02:55:24 +00:00
2006-06-07 18:54:56 +00:00
# include "asterisk.h"
ASTERISK_FILE_VERSION ( __FILE__ , " $Revision$ " )
2006-04-24 17:41:27 +00:00
# include <stdio.h>
# include <stdlib.h>
# include <string.h>
2006-06-07 18:54:56 +00:00
2006-04-24 17:41:27 +00:00
# include "asterisk/logger.h"
(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
2008-03-07 18:57:57 +00:00
# include "asterisk/lock.h"
# include "asterisk/hashtab.h"
2006-04-24 17:41:27 +00:00
# include "asterisk/ael_structs.h"
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
2008-08-19 15:59:12 +00:00
# include "asterisk/utils.h"
2006-04-24 17:41:27 +00:00
2008-08-19 16:31:24 +00:00
extern struct ast_flags ast_compat ;
2007-08-15 19:21:27 +00:00
pval * linku1 ( pval * head , pval * tail ) ;
2006-08-07 12:59:47 +00:00
static void set_dads ( pval * dad , pval * child_list ) ;
2006-04-26 22:41:16 +00:00
void reset_parencount ( yyscan_t yyscanner ) ;
void reset_semicount ( yyscan_t yyscanner ) ;
void reset_argcount ( yyscan_t yyscanner ) ;
2007-08-15 19:21:27 +00:00
2006-04-24 17:41:27 +00:00
# define YYLEX_PARAM ((struct parse_io *)parseio)->scanner
# define YYERROR_VERBOSE 1
extern char * my_file ;
# ifdef AAL_ARGCHECK
int ael_is_funcname ( char * name ) ;
# endif
2007-09-27 00:06:06 +00:00
static char * ael_token_subst ( const char * mess ) ;
2006-04-26 18:43:29 +00:00
2006-04-24 17:41:27 +00:00
/* Enabling traces. */
# ifndef YYDEBUG
# define YYDEBUG 0
# endif
/* Enabling verbose error messages. */
# ifdef YYERROR_VERBOSE
# undef YYERROR_VERBOSE
# define YYERROR_VERBOSE 1
# else
# define YYERROR_VERBOSE 1
# endif
/* Enabling the token table. */
# ifndef YYTOKEN_TABLE
# define YYTOKEN_TABLE 0
# endif
2006-06-18 21:36:24 +00:00
# if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
typedef union YYSTYPE
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
2008-09-03 14:01:27 +00:00
# line 59 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-30 12:44:54 +00:00
int intval ; /* integer value, typically flags */
char * str ; /* strings */
struct pval * pval ; /* full objects */
2006-06-18 21:36:24 +00:00
}
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
2008-08-19 15:59:12 +00:00
/* Line 187 of yacc.c. */
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
2008-09-03 14:01:27 +00:00
# line 253 "ael.tab.c"
2006-06-18 21:36:24 +00:00
YYSTYPE ;
2006-04-24 17:41:27 +00:00
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
# define YYSTYPE_IS_TRIVIAL 1
# endif
2006-06-18 21:36:24 +00:00
# if ! defined YYLTYPE && ! defined YYLTYPE_IS_DECLARED
2006-04-24 17:41:27 +00:00
typedef struct YYLTYPE
{
int first_line ;
int first_column ;
int last_line ;
int last_column ;
} YYLTYPE ;
# define yyltype YYLTYPE /* obsolescent; will be withdrawn */
# define YYLTYPE_IS_DECLARED 1
# define YYLTYPE_IS_TRIVIAL 1
# endif
/* Copy the second part of user declarations. */
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
2008-09-03 14:01:27 +00:00
# line 65 "ael.y"
2006-04-24 17:41:27 +00:00
/* declaring these AFTER the union makes things a lot simpler! */
void yyerror ( YYLTYPE * locp , struct parse_io * parseio , char const * s ) ;
int ael_yylex ( YYSTYPE * yylval_param , YYLTYPE * yylloc_param , void * yyscanner ) ;
2006-04-26 18:43:29 +00:00
2006-04-30 13:57:08 +00:00
/* create a new object with start-end marker */
2007-08-15 19:21:27 +00:00
pval * npval ( pvaltype type , int first_line , int last_line ,
2006-04-30 13:57:08 +00:00
int first_column , int last_column ) ;
2006-04-27 18:09:20 +00:00
/* create a new object with start-end marker, simplified interface.
* Must be declared here because YYLTYPE is not known before
*/
static pval * npval2 ( pvaltype type , YYLTYPE * first , YYLTYPE * last ) ;
2006-04-24 17:41:27 +00:00
2006-04-30 13:57:08 +00:00
/* another frontend for npval, this time for a string */
static pval * nword ( char * string , YYLTYPE * pos ) ;
2006-04-30 12:12:39 +00:00
/* update end position of an object, return the object */
static pval * update_last ( pval * , YYLTYPE * ) ;
2006-04-24 17:41:27 +00:00
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
2008-08-19 15:59:12 +00:00
/* Line 216 of yacc.c. */
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
2008-09-03 14:01:27 +00:00
# line 298 "ael.tab.c"
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
# ifdef short
# undef short
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_UINT8
typedef YYTYPE_UINT8 yytype_uint8 ;
# else
typedef unsigned char yytype_uint8 ;
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_INT8
typedef YYTYPE_INT8 yytype_int8 ;
# elif (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
typedef signed char yytype_int8 ;
# else
typedef short int yytype_int8 ;
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_UINT16
typedef YYTYPE_UINT16 yytype_uint16 ;
# else
typedef unsigned short int yytype_uint16 ;
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_INT16
typedef YYTYPE_INT16 yytype_int16 ;
# else
typedef short int yytype_int16 ;
# endif
# ifndef YYSIZE_T
# ifdef __SIZE_TYPE__
# define YYSIZE_T __SIZE_TYPE__
# elif defined size_t
# define YYSIZE_T size_t
# elif ! defined YYSIZE_T && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
# include <stddef.h> /* INFRINGES ON USER NAME SPACE */
# define YYSIZE_T size_t
# else
# define YYSIZE_T unsigned int
# endif
# endif
# define YYSIZE_MAXIMUM ((YYSIZE_T) -1)
2006-04-24 17:41:27 +00:00
# ifndef YY_
2007-06-05 22:04:22 +00:00
# if YYENABLE_NLS
2006-04-24 17:41:27 +00:00
# if ENABLE_NLS
# include <libintl.h> /* INFRINGES ON USER NAME SPACE */
# define YY_(msgid) dgettext ("bison-runtime", msgid)
# endif
# endif
# ifndef YY_
# define YY_(msgid) msgid
# endif
# endif
2006-06-18 21:36:24 +00:00
/* Suppress unused-variable warnings by "using" E. */
# if ! defined lint || defined __GNUC__
# define YYUSE(e) ((void) (e))
# else
# define YYUSE(e) /* empty */
# endif
/* Identity function, used to suppress warnings about constant conditions. */
# ifndef lint
# define YYID(n) (n)
# else
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
static int
YYID ( int i )
# else
static int
YYID ( i )
int i ;
# endif
{
return i ;
}
# endif
# if ! defined yyoverflow || YYERROR_VERBOSE
2006-04-24 17:41:27 +00:00
/* The parser invokes alloca or malloc; define the necessary symbols. */
# ifdef YYSTACK_USE_ALLOCA
# if YYSTACK_USE_ALLOCA
# ifdef __GNUC__
# define YYSTACK_ALLOC __builtin_alloca
2006-06-18 21:36:24 +00:00
# elif defined __BUILTIN_VA_ARG_INCR
# include <alloca.h> /* INFRINGES ON USER NAME SPACE */
# elif defined _AIX
# define YYSTACK_ALLOC __alloca
# elif defined _MSC_VER
# include <malloc.h> /* INFRINGES ON USER NAME SPACE */
# define alloca _alloca
2006-04-24 17:41:27 +00:00
# else
# define YYSTACK_ALLOC alloca
2006-06-18 21:36:24 +00:00
# if ! defined _ALLOCA_H && ! defined _STDLIB_H && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
# include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
2006-06-18 21:36:24 +00:00
# ifndef _STDLIB_H
# define _STDLIB_H 1
# endif
2006-04-24 17:41:27 +00:00
# endif
# endif
# endif
# endif
# ifdef YYSTACK_ALLOC
2006-06-18 21:36:24 +00:00
/* Pacify GCC's `empty if-body' warning. */
# define YYSTACK_FREE(Ptr) do { /* empty */ ; } while (YYID (0))
2006-04-24 17:41:27 +00:00
# ifndef YYSTACK_ALLOC_MAXIMUM
/* The OS might guarantee only one guard page at the bottom of the stack,
and a page size can be as small as 4096 bytes . So we cannot safely
invoke alloca ( N ) if N exceeds 4096. Use a slightly smaller number
to allow for a few compiler - allocated temporary stack slots . */
2006-06-18 21:36:24 +00:00
# define YYSTACK_ALLOC_MAXIMUM 4032 /* reasonable circa 2006 */
2006-04-24 17:41:27 +00:00
# endif
# else
# define YYSTACK_ALLOC YYMALLOC
# define YYSTACK_FREE YYFREE
# ifndef YYSTACK_ALLOC_MAXIMUM
2006-06-18 21:36:24 +00:00
# define YYSTACK_ALLOC_MAXIMUM YYSIZE_MAXIMUM
2006-04-24 17:41:27 +00:00
# endif
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
2008-08-19 15:59:12 +00:00
# if (defined __cplusplus && ! defined _STDLIB_H \
& & ! ( ( defined YYMALLOC | | defined malloc ) \
& & ( defined YYFREE | | defined free ) ) )
# include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
# ifndef _STDLIB_H
# define _STDLIB_H 1
# endif
2006-04-24 17:41:27 +00:00
# endif
# ifndef YYMALLOC
# define YYMALLOC malloc
2006-06-18 21:36:24 +00:00
# if ! defined malloc && ! defined _STDLIB_H && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
void * malloc ( YYSIZE_T ) ; /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# ifndef YYFREE
# define YYFREE free
2006-06-18 21:36:24 +00:00
# if ! defined free && ! defined _STDLIB_H && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
void free ( void * ) ; /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# endif
2006-06-18 21:36:24 +00:00
# endif /* ! defined yyoverflow || YYERROR_VERBOSE */
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
# if (! defined yyoverflow \
& & ( ! defined __cplusplus \
| | ( defined YYLTYPE_IS_TRIVIAL & & YYLTYPE_IS_TRIVIAL \
& & defined YYSTYPE_IS_TRIVIAL & & YYSTYPE_IS_TRIVIAL ) ) )
2006-04-24 17:41:27 +00:00
/* A type that is properly aligned for any stack member. */
union yyalloc
{
2006-06-18 21:36:24 +00:00
yytype_int16 yyss ;
2006-04-24 17:41:27 +00:00
YYSTYPE yyvs ;
YYLTYPE yyls ;
} ;
/* The size of the maximum gap between one aligned stack and the next. */
# define YYSTACK_GAP_MAXIMUM (sizeof (union yyalloc) - 1)
/* The size of an array large to enough to hold all stacks, each with
N elements . */
# define YYSTACK_BYTES(N) \
2006-06-18 21:36:24 +00:00
( ( N ) * ( sizeof ( yytype_int16 ) + sizeof ( YYSTYPE ) + sizeof ( YYLTYPE ) ) \
2006-04-24 17:41:27 +00:00
+ 2 * YYSTACK_GAP_MAXIMUM )
/* Copy COUNT objects from FROM to TO. The source and destination do
not overlap . */
# ifndef YYCOPY
2006-06-18 21:36:24 +00:00
# if defined __GNUC__ && 1 < __GNUC__
2006-04-24 17:41:27 +00:00
# define YYCOPY(To, From, Count) \
__builtin_memcpy ( To , From , ( Count ) * sizeof ( * ( From ) ) )
# else
# define YYCOPY(To, From, Count) \
do \
{ \
YYSIZE_T yyi ; \
for ( yyi = 0 ; yyi < ( Count ) ; yyi + + ) \
( To ) [ yyi ] = ( From ) [ yyi ] ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# endif
# endif
/* Relocate STACK from its old location to the new one. The
local variables YYSIZE and YYSTACKSIZE give the old and new number of
elements in the stack , and YYPTR gives the new location of the
stack . Advance YYPTR to a properly aligned location for the next
stack . */
# define YYSTACK_RELOCATE(Stack) \
do \
{ \
YYSIZE_T yynewbytes ; \
YYCOPY ( & yyptr - > Stack , Stack , yysize ) ; \
Stack = & yyptr - > Stack ; \
yynewbytes = yystacksize * sizeof ( * Stack ) + YYSTACK_GAP_MAXIMUM ; \
yyptr + = yynewbytes / sizeof ( * yyptr ) ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
/* YYFINAL -- State number of the termination state. */
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
2007-10-26 17:39:39 +00:00
# define YYFINAL 17
2006-04-24 17:41:27 +00:00
/* YYLAST -- Last index in YYTABLE. */
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# define YYLAST 373
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
/* YYNTOKENS -- Number of terminals. */
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
2007-10-26 17:39:39 +00:00
# define YYNTOKENS 44
2006-06-18 21:36:24 +00:00
/* YYNNTS -- Number of nonterminals. */
2007-06-20 20:10:19 +00:00
# define YYNNTS 56
2006-06-18 21:36:24 +00:00
/* YYNRULES -- Number of rules. */
2007-11-27 18:50:44 +00:00
# define YYNRULES 142
2006-06-18 21:36:24 +00:00
/* YYNRULES -- Number of states. */
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# define YYNSTATES 281
2006-04-24 17:41:27 +00:00
/* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX. */
# define YYUNDEFTOK 2
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
2007-10-26 17:39:39 +00:00
# define YYMAXUTOK 298
2006-04-24 17:41:27 +00:00
# define YYTRANSLATE(YYX) \
( ( unsigned int ) ( YYX ) < = YYMAXUTOK ? yytranslate [ YYX ] : YYUNDEFTOK )
/* YYTRANSLATE[YYLEX] -- Bison symbol number corresponding to YYLEX. */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yytranslate [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 1 , 2 , 3 , 4 ,
5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 ,
15 , 16 , 17 , 18 , 19 , 20 , 21 , 22 , 23 , 24 ,
25 , 26 , 27 , 28 , 29 , 30 , 31 , 32 , 33 , 34 ,
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
2007-10-26 17:39:39 +00:00
35 , 36 , 37 , 38 , 39 , 40 , 41 , 42 , 43
2006-04-24 17:41:27 +00:00
} ;
# if YYDEBUG
/* YYPRHS[YYN] -- Index of the first RHS symbol of rule number YYN in
YYRHS . */
2006-06-18 21:36:24 +00:00
static const yytype_uint16 yyprhs [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 0 , 3 , 5 , 7 , 10 , 13 , 15 , 17 , 19 ,
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
2007-10-26 17:39:39 +00:00
21 , 23 , 25 , 32 , 34 , 35 , 37 , 40 , 43 , 52 ,
57 , 58 , 61 , 64 , 65 , 71 , 72 , 79 , 80 , 82 ,
86 , 89 , 90 , 93 , 96 , 98 , 100 , 102 , 104 , 106 ,
2007-11-27 18:50:44 +00:00
108 , 110 , 113 , 115 , 120 , 124 , 130 , 135 , 143 , 152 ,
153 , 156 , 159 , 165 , 167 , 175 , 176 , 181 , 184 , 187 ,
192 , 194 , 197 , 199 , 202 , 206 , 210 , 212 , 215 , 219 ,
221 , 224 , 228 , 234 , 238 , 240 , 242 , 246 , 250 , 253 ,
254 , 255 , 256 , 269 , 273 , 275 , 279 , 282 , 285 , 286 ,
292 , 295 , 298 , 301 , 305 , 307 , 310 , 311 , 313 , 317 ,
321 , 327 , 333 , 339 , 345 , 346 , 349 , 352 , 357 , 358 ,
364 , 368 , 369 , 373 , 377 , 380 , 382 , 383 , 385 , 386 ,
390 , 391 , 394 , 399 , 403 , 408 , 409 , 412 , 414 , 416 ,
422 , 427 , 432 , 433 , 437 , 443 , 446 , 448 , 452 , 455 ,
459 , 462 , 467
2006-04-24 17:41:27 +00:00
} ;
2006-06-18 21:36:24 +00:00
/* YYRHS -- A `-1'-separated list of the rules' RHS. */
static const yytype_int8 yyrhs [ ] =
2006-04-24 17:41:27 +00:00
{
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
2007-10-26 17:39:39 +00:00
45 , 0 , - 1 , 46 , - 1 , 47 , - 1 , 46 , 47 , - 1 ,
46 , 1 , - 1 , 49 , - 1 , 51 , - 1 , 52 , - 1 , 8 ,
- 1 , 43 , - 1 , 37 , - 1 , 50 , 3 , 48 , 4 , 59 ,
5 , - 1 , 23 , - 1 , - 1 , 24 , - 1 , 24 , 23 , - 1 ,
23 , 24 , - 1 , 15 , 43 , 6 , 58 , 7 , 4 , 92 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
5 , - 1 , 16 , 4 , 53 , 5 , - 1 , - 1 , 53 , 54 ,
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
2007-10-26 17:39:39 +00:00
- 1 , 1 , 53 , - 1 , - 1 , 43 , 9 , 55 , 43 , 8 ,
- 1 , - 1 , 42 , 43 , 9 , 57 , 43 , 8 , - 1 , - 1 ,
43 , - 1 , 58 , 10 , 43 , - 1 , 58 , 1 , - 1 , - 1 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
59 , 60 , - 1 , 1 , 59 , - 1 , 62 , - 1 , 99 , - 1 ,
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
2007-10-26 17:39:39 +00:00
94 , - 1 , 95 , - 1 , 61 , - 1 , 54 , - 1 , 56 , - 1 ,
43 , 1 , - 1 , 8 , - 1 , 17 , 25 , 43 , 8 , - 1 ,
2007-11-27 18:50:44 +00:00
43 , 25 , 74 , - 1 , 43 , 14 , 43 , 25 , 74 , - 1 ,
31 , 43 , 25 , 74 , - 1 , 32 , 6 , 70 , 7 , 43 ,
25 , 74 , - 1 , 31 , 32 , 6 , 70 , 7 , 43 , 25 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
74 , - 1 , - 1 , 63 , 74 , - 1 , 1 , 63 , - 1 , 71 ,
2007-11-27 18:50:44 +00:00
11 , 71 , 11 , 71 , - 1 , 43 , - 1 , 64 , 13 , 71 ,
13 , 71 , 13 , 71 , - 1 , - 1 , 6 , 67 , 69 , 7 ,
- 1 , 19 , 66 , - 1 , 22 , 66 , - 1 , 20 , 6 , 65 ,
7 , - 1 , 43 , - 1 , 43 , 43 , - 1 , 43 , - 1 , 70 ,
43 , - 1 , 70 , 11 , 43 , - 1 , 70 , 12 , 43 , - 1 ,
43 , - 1 , 43 , 43 , - 1 , 43 , 43 , 43 , - 1 , 43 ,
- 1 , 43 , 43 , - 1 , 72 , 11 , 43 , - 1 , 18 , 66 ,
4 , 90 , 5 , - 1 , 4 , 63 , 5 , - 1 , 54 , - 1 ,
56 , - 1 , 26 , 80 , 8 , - 1 , 27 , 82 , 8 , - 1 ,
43 , 11 , - 1 , - 1 , - 1 , - 1 , 33 , 6 , 75 , 43 ,
8 , 76 , 43 , 8 , 77 , 43 , 7 , 74 , - 1 , 34 ,
66 , 74 , - 1 , 73 , - 1 , 12 , 83 , 8 , - 1 , 87 ,
8 , - 1 , 43 , 8 , - 1 , - 1 , 87 , 9 , 78 , 43 ,
8 , - 1 , 29 , 8 , - 1 , 28 , 8 , - 1 , 30 , 8 ,
- 1 , 68 , 74 , 79 , - 1 , 8 , - 1 , 21 , 74 , - 1 ,
- 1 , 72 , - 1 , 72 , 13 , 72 , - 1 , 72 , 10 , 72 ,
- 1 , 72 , 13 , 72 , 13 , 72 , - 1 , 72 , 10 , 72 ,
10 , 72 , - 1 , 37 , 13 , 72 , 13 , 72 , - 1 , 37 ,
10 , 72 , 10 , 72 , - 1 , - 1 , 10 , 43 , - 1 , 72 ,
81 , - 1 , 72 , 81 , 14 , 48 , - 1 , - 1 , 43 , 6 ,
84 , 89 , 7 , - 1 , 43 , 6 , 7 , - 1 , - 1 , 43 ,
6 , 86 , - 1 , 85 , 89 , 7 , - 1 , 85 , 7 , - 1 ,
43 , - 1 , - 1 , 69 , - 1 , - 1 , 89 , 10 , 88 , - 1 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
- 1 , 90 , 91 , - 1 , 35 , 43 , 11 , 63 , - 1 , 37 ,
11 , 63 , - 1 , 36 , 43 , 11 , 63 , - 1 , - 1 , 92 ,
93 , - 1 , 74 , - 1 , 99 , - 1 , 38 , 43 , 4 , 63 ,
2007-11-27 18:50:44 +00:00
5 , - 1 , 39 , 4 , 96 , 5 , - 1 , 40 , 4 , 96 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
5 , - 1 , - 1 , 96 , 43 , 8 , - 1 , 96 , 43 , 14 ,
43 , 8 , - 1 , 1 , 96 , - 1 , 48 , - 1 , 48 , 13 ,
2007-11-27 18:50:44 +00:00
65 , - 1 , 97 , 8 , - 1 , 98 , 97 , 8 , - 1 , 98 ,
1 , - 1 , 41 , 4 , 98 , 5 , - 1 , 41 , 4 , 5 ,
- 1
2006-04-24 17:41:27 +00:00
} ;
/* YYRLINE[YYN] -- source line where rule number YYN was defined. */
2006-06-18 21:36:24 +00:00
static const yytype_uint16 yyrline [ ] =
2006-04-24 17:41:27 +00:00
{
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
2008-09-03 14:01:27 +00:00
0 , 191 , 191 , 194 , 195 , 196 , 199 , 200 , 201 , 202 ,
205 , 206 , 209 , 218 , 219 , 220 , 221 , 222 , 225 , 231 ,
237 , 238 , 239 , 242 , 242 , 248 , 248 , 255 , 256 , 257 ,
258 , 261 , 262 , 263 , 266 , 267 , 268 , 269 , 270 , 271 ,
272 , 273 , 274 , 277 , 282 , 286 , 294 , 299 , 304 , 313 ,
2008-11-02 18:52:13 +00:00
314 , 315 , 321 , 331 , 335 , 343 , 343 , 347 , 350 , 353 ,
364 , 365 , 377 , 378 , 387 , 396 , 407 , 408 , 418 , 431 ,
432 , 441 , 452 , 461 , 464 , 465 , 466 , 469 , 472 , 475 ,
476 , 477 , 475 , 483 , 487 , 488 , 489 , 490 , 493 , 493 ,
526 , 527 , 528 , 529 , 533 , 536 , 537 , 540 , 541 , 544 ,
547 , 551 , 555 , 559 , 565 , 566 , 570 , 573 , 579 , 579 ,
584 , 592 , 592 , 603 , 610 , 613 , 614 , 617 , 618 , 621 ,
624 , 625 , 628 , 632 , 636 , 642 , 643 , 646 , 647 , 648 ,
654 , 659 , 664 , 665 , 666 , 677 , 680 , 681 , 688 , 689 ,
690 , 693 , 696
2006-04-24 17:41:27 +00:00
} ;
# endif
# if YYDEBUG || YYERROR_VERBOSE || YYTOKEN_TABLE
/* YYTNAME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
2006-06-18 21:36:24 +00:00
First , the terminals , then , starting at YYNTOKENS , nonterminals . */
2006-04-24 17:41:27 +00:00
static const char * const yytname [ ] =
{
" $end " , " error " , " $undefined " , " KW_CONTEXT " , " LC " , " RC " , " LP " , " RP " ,
" SEMI " , " EQ " , " COMMA " , " COLON " , " AMPER " , " BAR " , " AT " , " KW_MACRO " ,
" KW_GLOBALS " , " KW_IGNOREPAT " , " KW_SWITCH " , " KW_IF " , " KW_IFTIME " ,
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
2007-10-26 17:39:39 +00:00
" KW_ELSE " , " KW_RANDOM " , " KW_ABSTRACT " , " KW_EXTEND " , " EXTENMARK " ,
" KW_GOTO " , " KW_JUMP " , " KW_RETURN " , " KW_BREAK " , " KW_CONTINUE " ,
" KW_REGEXTEN " , " KW_HINT " , " KW_FOR " , " KW_WHILE " , " KW_CASE " , " KW_PATTERN " ,
" KW_DEFAULT " , " KW_CATCH " , " KW_SWITCHES " , " KW_ESWITCHES " , " KW_INCLUDES " ,
" KW_LOCAL " , " word " , " $accept " , " file " , " objects " , " object " ,
" context_name " , " context " , " opt_abstract " , " macro " , " globals " ,
" global_statements " , " assignment " , " @1 " , " local_assignment " , " @2 " ,
" arglist " , " elements " , " element " , " ignorepat " , " extension " , " statements " ,
" timerange " , " timespec " , " test_expr " , " @3 " , " if_like_head " , " word_list " ,
" hint_word " , " word3_list " , " goto_word " , " switch_statement " , " statement " ,
" @4 " , " @5 " , " @6 " , " @7 " , " opt_else " , " target " , " opt_pri " , " jumptarget " ,
" macro_call " , " @8 " , " application_call_head " , " @9 " , " application_call " ,
" opt_word " , " eval_arglist " , " case_statements " , " case_statement " ,
" macro_statements " , " macro_statement " , " switches " , " eswitches " ,
" switchlist " , " included_entry " , " includeslist " , " includes " , 0
2006-04-24 17:41:27 +00:00
} ;
# endif
# ifdef YYPRINT
/* YYTOKNUM[YYLEX-NUM] -- Internal token number corresponding to
token YYLEX - NUM . */
2006-06-18 21:36:24 +00:00
static const yytype_uint16 yytoknum [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 256 , 257 , 258 , 259 , 260 , 261 , 262 , 263 , 264 ,
265 , 266 , 267 , 268 , 269 , 270 , 271 , 272 , 273 , 274 ,
275 , 276 , 277 , 278 , 279 , 280 , 281 , 282 , 283 , 284 ,
285 , 286 , 287 , 288 , 289 , 290 , 291 , 292 , 293 , 294 ,
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
2007-10-26 17:39:39 +00:00
295 , 296 , 297 , 298
2006-04-24 17:41:27 +00:00
} ;
# endif
/* YYR1[YYN] -- Symbol number of symbol that rule YYN derives. */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yyr1 [ ] =
2006-04-24 17:41:27 +00:00
{
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
2007-10-26 17:39:39 +00:00
0 , 44 , 45 , 46 , 46 , 46 , 47 , 47 , 47 , 47 ,
48 , 48 , 49 , 50 , 50 , 50 , 50 , 50 , 51 , 52 ,
53 , 53 , 53 , 55 , 54 , 57 , 56 , 58 , 58 , 58 ,
58 , 59 , 59 , 59 , 60 , 60 , 60 , 60 , 60 , 60 ,
2007-11-27 18:50:44 +00:00
60 , 60 , 60 , 61 , 62 , 62 , 62 , 62 , 62 , 63 ,
63 , 63 , 64 , 64 , 65 , 67 , 66 , 68 , 68 , 68 ,
69 , 69 , 70 , 70 , 70 , 70 , 71 , 71 , 71 , 72 ,
72 , 72 , 73 , 74 , 74 , 74 , 74 , 74 , 74 , 75 ,
76 , 77 , 74 , 74 , 74 , 74 , 74 , 74 , 78 , 74 ,
74 , 74 , 74 , 74 , 74 , 79 , 79 , 80 , 80 , 80 ,
80 , 80 , 80 , 80 , 81 , 81 , 82 , 82 , 84 , 83 ,
83 , 86 , 85 , 87 , 87 , 88 , 88 , 89 , 89 , 89 ,
90 , 90 , 91 , 91 , 91 , 92 , 92 , 93 , 93 , 93 ,
94 , 95 , 96 , 96 , 96 , 96 , 97 , 97 , 98 , 98 ,
98 , 99 , 99
2006-04-24 17:41:27 +00:00
} ;
/* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN. */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yyr2 [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 2 , 1 , 1 , 2 , 2 , 1 , 1 , 1 , 1 ,
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
2007-10-26 17:39:39 +00:00
1 , 1 , 6 , 1 , 0 , 1 , 2 , 2 , 8 , 4 ,
0 , 2 , 2 , 0 , 5 , 0 , 6 , 0 , 1 , 3 ,
2 , 0 , 2 , 2 , 1 , 1 , 1 , 1 , 1 , 1 ,
2007-11-27 18:50:44 +00:00
1 , 2 , 1 , 4 , 3 , 5 , 4 , 7 , 8 , 0 ,
2 , 2 , 5 , 1 , 7 , 0 , 4 , 2 , 2 , 4 ,
1 , 2 , 1 , 2 , 3 , 3 , 1 , 2 , 3 , 1 ,
2 , 3 , 5 , 3 , 1 , 1 , 3 , 3 , 2 , 0 ,
0 , 0 , 12 , 3 , 1 , 3 , 2 , 2 , 0 , 5 ,
2 , 2 , 2 , 3 , 1 , 2 , 0 , 1 , 3 , 3 ,
5 , 5 , 5 , 5 , 0 , 2 , 2 , 4 , 0 , 5 ,
3 , 0 , 3 , 3 , 2 , 1 , 0 , 1 , 0 , 3 ,
0 , 2 , 4 , 3 , 4 , 0 , 2 , 1 , 1 , 5 ,
4 , 4 , 0 , 3 , 5 , 2 , 1 , 3 , 2 , 3 ,
2 , 4 , 3
2006-04-24 17:41:27 +00:00
} ;
/* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state
STATE - NUM when YYTABLE doesn ' t specify something else to do . Zero
means the default is an error . */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yydefact [ ] =
2006-04-24 17:41:27 +00:00
{
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
2007-10-26 17:39:39 +00:00
14 , 9 , 0 , 0 , 13 , 15 , 0 , 0 , 3 , 6 ,
0 , 7 , 8 , 0 , 0 , 17 , 16 , 1 , 5 , 4 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
0 , 27 , 0 , 0 , 11 , 10 , 0 , 28 , 0 , 22 ,
19 , 0 , 21 , 0 , 30 , 0 , 0 , 23 , 0 , 0 ,
125 , 29 , 0 , 33 , 12 , 42 , 0 , 0 , 0 , 0 ,
0 , 0 , 0 , 0 , 39 , 40 , 32 , 38 , 34 , 36 ,
37 , 35 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ,
0 , 0 , 41 , 0 , 0 , 0 , 18 , 94 , 0 , 0 ,
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
2007-10-26 17:39:39 +00:00
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
0 , 0 , 74 , 75 , 0 , 84 , 127 , 118 , 0 , 126 ,
128 , 24 , 0 , 0 , 0 , 62 , 0 , 0 , 0 , 0 ,
142 , 136 , 0 , 0 , 25 , 0 , 44 , 0 , 0 , 0 ,
0 , 55 , 0 , 57 , 0 , 58 , 0 , 69 , 97 , 0 ,
104 , 0 , 91 , 90 , 92 , 79 , 0 , 0 , 111 , 87 ,
78 , 96 , 114 , 60 , 117 , 0 , 86 , 88 , 43 , 0 ,
46 , 0 , 0 , 0 , 63 , 135 , 130 , 0 , 131 , 0 ,
138 , 140 , 141 , 0 , 0 , 0 , 51 , 73 , 50 , 108 ,
85 , 0 , 120 , 53 , 0 , 0 , 0 , 0 , 0 , 70 ,
0 , 0 , 0 , 76 , 0 , 106 , 77 , 0 , 83 , 0 ,
112 , 0 , 93 , 61 , 113 , 116 , 0 , 0 , 0 , 64 ,
65 , 133 , 0 , 137 , 139 , 0 , 45 , 110 , 118 , 0 ,
0 , 67 , 0 , 59 , 0 , 0 , 0 , 99 , 71 , 98 ,
2007-11-27 18:50:44 +00:00
105 , 0 , 0 , 0 , 95 , 115 , 119 , 0 , 0 , 0 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
0 , 26 , 0 , 56 , 72 , 0 , 0 , 0 , 121 , 68 ,
2007-11-27 18:50:44 +00:00
66 , 0 , 0 , 0 , 0 , 0 , 0 , 107 , 80 , 129 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
89 , 0 , 47 , 134 , 109 , 0 , 0 , 0 , 0 , 0 ,
103 , 102 , 101 , 100 , 0 , 48 , 0 , 0 , 123 , 0 ,
52 , 0 , 122 , 124 , 0 , 81 , 54 , 0 , 0 , 0 ,
82
2006-04-24 17:41:27 +00:00
} ;
2006-06-18 21:36:24 +00:00
/* YYDEFGOTO[NTERM-NUM]. */
static const yytype_int16 yydefgoto [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
- 1 , 6 , 7 , 8 , 111 , 9 , 10 , 11 , 12 , 23 ,
92 , 42 , 93 , 164 , 28 , 39 , 56 , 57 , 58 , 118 ,
174 , 175 , 122 , 171 , 94 , 144 , 106 , 176 , 128 , 95 ,
168 , 187 , 264 , 277 , 196 , 192 , 129 , 185 , 131 , 120 ,
208 , 97 , 190 , 98 , 226 , 145 , 210 , 238 , 62 , 99 ,
59 , 60 , 108 , 112 , 113 , 61
2006-04-24 17:41:27 +00:00
} ;
/* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
STATE - NUM . */
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# define YYPACT_NINF -209
2006-06-18 21:36:24 +00:00
static const yytype_int16 yypact [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
262 , - 209 , - 32 , 21 , 5 , 13 , 69 , 296 , - 209 , - 209 ,
112 , - 209 , - 209 , 115 , 14 , - 209 , - 209 , - 209 , - 209 , - 209 ,
- 29 , 85 , 14 , 0 , - 209 , - 209 , 129 , - 209 , 116 , 92 ,
- 209 , 140 , - 209 , 105 , - 209 , 147 , 125 , - 209 , 105 , 99 ,
- 209 , - 209 , 132 , 252 , - 209 , - 209 , 163 , - 25 , 159 , 182 ,
186 , 197 , 162 , 242 , - 209 , - 209 , - 209 , - 209 , - 209 , - 209 ,
- 209 , - 209 , 165 , 201 , 170 , 222 , 204 , 187 , 16 , 16 ,
68 , 223 , - 209 , 190 , 246 , 59 , - 209 , - 209 , 193 , 234 ,
234 , 236 , 234 , - 27 , 212 , 249 , 251 , 255 , 238 , 234 ,
228 , 292 , - 209 , - 209 , 246 , - 209 , - 209 , 15 , 146 , - 209 ,
- 209 , - 209 , 273 , 187 , 246 , - 209 , 107 , 16 , 25 , 29 ,
- 209 , 269 , 279 , 39 , - 209 , 265 , - 209 , 19 , 192 , 299 ,
294 , - 209 , 302 , - 209 , 264 , - 209 , 70 , 266 , 161 , 300 ,
168 , 305 , - 209 , - 209 , - 209 , - 209 , 246 , 306 , - 209 , - 209 ,
- 209 , 293 , - 209 , 272 , - 209 , 84 , - 209 , - 209 , - 209 , 113 ,
- 209 , 274 , 275 , 278 , - 209 , 280 , - 209 , 76 , - 209 , 264 ,
- 209 , - 209 , - 209 , 308 , 281 , 246 , 246 , - 209 , - 209 , 315 ,
- 209 , 282 , - 209 , 22 , 313 , 320 , 317 , 212 , 212 , - 209 ,
212 , 286 , 212 , - 209 , 287 , 318 , - 209 , 288 , - 209 , 59 ,
- 209 , 246 , - 209 , - 209 , - 209 , 290 , 291 , 295 , 310 , - 209 ,
- 209 , - 209 , 297 , - 209 , - 209 , 328 , - 209 , - 209 , 282 , 330 ,
122 , 298 , 301 , - 209 , 301 , 171 , 86 , 205 , - 209 , 121 ,
- 209 , - 29 , 331 , 219 , - 209 , - 209 , - 209 , 334 , 321 , 246 ,
335 , - 209 , 102 , - 209 , - 209 , 304 , 307 , 337 , - 209 , - 209 ,
309 , 332 , 338 , 212 , 212 , 212 , 212 , - 209 , - 209 , - 209 ,
- 209 , 246 , - 209 , - 209 , - 209 , 340 , 342 , 19 , 301 , 301 ,
343 , 343 , 343 , 343 , 312 , - 209 , 19 , 19 , 246 , 344 ,
- 209 , 348 , 246 , 246 , 301 , - 209 , - 209 , 316 , 351 , 246 ,
- 209
2006-04-24 17:41:27 +00:00
} ;
/* YYPGOTO[NTERM-NUM]. */
2006-06-18 21:36:24 +00:00
static const yytype_int16 yypgoto [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
- 209 , - 209 , - 209 , 353 , - 19 , - 209 , - 209 , - 209 , - 209 , 339 ,
137 , - 209 , - 30 , - 209 , - 209 , 324 , - 209 , - 209 , - 209 , - 114 ,
- 209 , 206 , - 54 , - 209 , - 209 , 195 , 260 , - 208 , - 82 , - 209 ,
- 62 , - 209 , - 209 , - 209 , - 209 , - 209 , - 209 , - 209 , - 209 , - 209 ,
- 209 , - 209 , - 209 , - 209 , - 209 , 156 , - 209 , - 209 , - 209 , - 209 ,
- 209 , - 209 , 1 , 254 , - 209 , 311
2006-04-24 17:41:27 +00:00
} ;
/* YYTABLE[YYPACT[STATE-NUM]]. What to do in state STATE-NUM. If
positive , shift that token . If negative , reduce the rule which
number is the opposite . If zero , do what YYDEFACT says .
If YYTABLE_NINF , syntax error . */
2007-11-27 18:50:44 +00:00
# define YYTABLE_NINF -133
2006-06-18 21:36:24 +00:00
static const yytype_int16 yytable [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
96 , 26 , 130 , 166 , 241 , 30 , 242 , 65 , 24 , 55 ,
126 , 13 , 116 , 55 , 25 , 22 , 127 , 107 , 66 , - 20 ,
117 , - 132 , 142 , - 49 , - 49 , 14 , 123 , - 49 , 125 , 15 ,
156 , - 49 , 141 , - 66 , 158 , 136 , 16 , - 49 , - 49 , - 49 ,
161 , - 49 , 150 , 31 , 162 , - 49 , - 49 , - 49 , - 49 , - 49 ,
269 , 270 , - 49 , - 49 , - 49 , - 49 , - 49 , - 20 , 143 , - 132 ,
117 , - 49 , - 49 , - 49 , - 49 , 211 , 276 , - 49 , 157 , 17 ,
109 , - 49 , 157 , 110 , 188 , 223 , 24 , - 49 , - 49 , - 49 ,
177 , - 49 , 25 , 178 , 201 , - 49 , - 49 , - 49 , - 49 , - 49 ,
202 , 194 , - 49 , - 49 , 195 , 215 , 216 , 181 , 217 , 244 ,
219 , - 49 , - 49 , 206 , 44 , 24 , 38 , 45 , 155 , 254 ,
- 31 , 25 , 195 , - 31 , 151 , 20 , 46 , 34 , 152 , 153 ,
197 , 21 , - 31 , 35 , 152 , 153 , 36 , 234 , 27 , 224 ,
47 , 48 , 181 , 33 , 246 , 31 , - 31 , - 31 , 49 , 50 ,
51 , 52 , 53 , 268 , - 31 , - 31 , - 31 , - 31 , - 31 , 37 ,
154 , 40 , 272 , 273 , 146 , 147 , 154 , 235 , 236 , 237 ,
32 , 260 , 261 , 262 , 263 , 67 , 32 , 252 , 41 , 75 ,
76 , 180 , 181 , 77 , 182 , 63 , 54 , 78 , 184 , 181 ,
54 , 243 , 181 , 79 , 80 , 81 , 68 , 82 , 64 , 265 ,
69 , 83 , 84 , 85 , 86 , 87 , 75 , 167 , 88 , 89 ,
77 , 70 , 247 , 90 , 78 , 71 , 51 , 52 , 91 , 101 ,
79 , 80 , 81 , 102 , 82 , 245 , 181 , 280 , 83 , 84 ,
85 , 86 , 87 , 75 , 249 , 88 , 89 , 77 , 103 , 104 ,
105 , 78 , 114 , 115 , 52 , 91 , 119 , 79 , 80 , 81 ,
121 , 82 , 124 , 72 , 135 , 83 , 84 , 85 , 86 , 87 ,
75 , 37 , 88 , 89 , 77 , 127 , 73 , 132 , 78 , 133 ,
45 , 52 , 91 , 134 , 79 , 80 , 81 , 74 , 82 , 46 ,
1 , 137 , 83 , 84 , 85 , 86 , 87 , 2 , 3 , 88 ,
89 , 148 , 159 , 47 , 48 , 4 , 5 , 160 , 52 , 91 ,
165 , 49 , 50 , 51 , 52 , 53 , - 2 , 18 , 138 , - 14 ,
139 , 37 , 170 , 140 , 1 , 169 , 172 , 173 , 183 , 179 ,
189 , 2 , 3 , 186 , 191 , 193 , 204 , 198 , 199 , 4 ,
5 , 200 , 207 , 157 , 205 , 143 , 212 , 213 , 214 , 218 ,
220 , 222 , 221 , 225 , 227 , 229 , 231 , 233 , 228 , 248 ,
230 , 239 , 250 , 253 , 240 , 258 , 251 , 255 , 257 , 259 ,
256 , 266 , 211 , 267 , 181 , 271 , 275 , 274 , 279 , 278 ,
19 , 29 , 43 , 149 , 232 , 203 , 209 , 163 , 0 , 0 ,
0 , 0 , 0 , 100
2006-04-24 17:41:27 +00:00
} ;
2007-11-27 18:50:44 +00:00
static const yytype_int16 yycheck [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
62 , 20 , 84 , 117 , 212 , 5 , 214 , 32 , 37 , 39 ,
37 , 43 , 74 , 43 , 43 , 1 , 43 , 1 , 43 , 5 ,
1 , 5 , 7 , 4 , 5 , 4 , 80 , 8 , 82 , 24 ,
5 , 12 , 94 , 11 , 5 , 89 , 23 , 18 , 19 , 20 ,
1 , 22 , 104 , 43 , 5 , 26 , 27 , 28 , 29 , 30 ,
258 , 259 , 33 , 34 , 35 , 36 , 37 , 43 , 43 , 43 ,
1 , 42 , 43 , 4 , 5 , 43 , 274 , 8 , 43 , 0 ,
69 , 12 , 43 , 5 , 136 , 189 , 37 , 18 , 19 , 20 ,
10 , 22 , 43 , 13 , 8 , 26 , 27 , 28 , 29 , 30 ,
14 , 7 , 33 , 34 , 10 , 177 , 178 , 11 , 180 , 13 ,
182 , 42 , 43 , 165 , 5 , 37 , 1 , 8 , 107 , 7 ,
5 , 43 , 10 , 8 , 7 , 3 , 17 , 1 , 11 , 12 ,
7 , 6 , 17 , 7 , 11 , 12 , 10 , 5 , 43 , 191 ,
31 , 32 , 11 , 4 , 13 , 43 , 31 , 32 , 39 , 40 ,
41 , 42 , 43 , 257 , 39 , 40 , 41 , 42 , 43 , 9 ,
43 , 4 , 266 , 267 , 8 , 9 , 43 , 35 , 36 , 37 ,
23 , 243 , 244 , 245 , 246 , 6 , 29 , 229 , 43 , 4 ,
5 , 10 , 11 , 8 , 13 , 43 , 39 , 12 , 10 , 11 ,
43 , 10 , 11 , 18 , 19 , 20 , 4 , 22 , 25 , 251 ,
4 , 26 , 27 , 28 , 29 , 30 , 4 , 5 , 33 , 34 ,
8 , 4 , 221 , 38 , 12 , 43 , 41 , 42 , 43 , 8 ,
18 , 19 , 20 , 43 , 22 , 10 , 11 , 279 , 26 , 27 ,
28 , 29 , 30 , 4 , 5 , 33 , 34 , 8 , 6 , 25 ,
43 , 12 , 9 , 43 , 42 , 43 , 43 , 18 , 19 , 20 ,
6 , 22 , 6 , 1 , 6 , 26 , 27 , 28 , 29 , 30 ,
4 , 9 , 33 , 34 , 8 , 43 , 14 , 8 , 12 , 8 ,
8 , 42 , 43 , 8 , 18 , 19 , 20 , 25 , 22 , 17 ,
8 , 43 , 26 , 27 , 28 , 29 , 30 , 15 , 16 , 33 ,
34 , 8 , 13 , 31 , 32 , 23 , 24 , 8 , 42 , 43 ,
25 , 39 , 40 , 41 , 42 , 43 , 0 , 1 , 6 , 3 ,
8 , 9 , 8 , 11 , 8 , 6 , 4 , 43 , 8 , 43 ,
4 , 15 , 16 , 8 , 21 , 43 , 8 , 43 , 43 , 23 ,
24 , 43 , 7 , 43 , 43 , 43 , 13 , 7 , 11 , 43 ,
43 , 43 , 14 , 43 , 43 , 25 , 8 , 7 , 43 , 8 ,
43 , 43 , 8 , 8 , 43 , 13 , 25 , 43 , 11 , 11 ,
43 , 11 , 43 , 11 , 11 , 43 , 8 , 13 , 7 , 43 ,
7 , 22 , 38 , 103 , 208 , 159 , 171 , 113 , - 1 , - 1 ,
- 1 , - 1 , - 1 , 62
2006-04-24 17:41:27 +00:00
} ;
/* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
symbol of state STATE - NUM . */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yystos [ ] =
2006-04-24 17:41:27 +00:00
{
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
2007-10-26 17:39:39 +00:00
0 , 8 , 15 , 16 , 23 , 24 , 45 , 46 , 47 , 49 ,
50 , 51 , 52 , 43 , 4 , 24 , 23 , 0 , 1 , 47 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
3 , 6 , 1 , 53 , 37 , 43 , 48 , 43 , 58 , 53 ,
5 , 43 , 54 , 4 , 1 , 7 , 10 , 9 , 1 , 59 ,
4 , 43 , 55 , 59 , 5 , 8 , 17 , 31 , 32 , 39 ,
40 , 41 , 42 , 43 , 54 , 56 , 60 , 61 , 62 , 94 ,
95 , 99 , 92 , 43 , 25 , 32 , 43 , 6 , 4 , 4 ,
4 , 43 , 1 , 14 , 25 , 4 , 5 , 8 , 12 , 18 ,
2007-11-27 18:50:44 +00:00
19 , 20 , 22 , 26 , 27 , 28 , 29 , 30 , 33 , 34 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
38 , 43 , 54 , 56 , 68 , 73 , 74 , 85 , 87 , 93 ,
99 , 8 , 43 , 6 , 25 , 43 , 70 , 1 , 96 , 96 ,
5 , 48 , 97 , 98 , 9 , 43 , 74 , 1 , 63 , 43 ,
83 , 6 , 66 , 66 , 6 , 66 , 37 , 43 , 72 , 80 ,
72 , 82 , 8 , 8 , 8 , 6 , 66 , 43 , 6 , 8 ,
11 , 74 , 7 , 43 , 69 , 89 , 8 , 9 , 8 , 70 ,
74 , 7 , 11 , 12 , 43 , 96 , 5 , 43 , 5 , 13 ,
8 , 1 , 5 , 97 , 57 , 25 , 63 , 5 , 74 , 6 ,
8 , 67 , 4 , 43 , 64 , 65 , 71 , 10 , 13 , 43 ,
10 , 11 , 13 , 8 , 10 , 81 , 8 , 75 , 74 , 4 ,
86 , 21 , 79 , 43 , 7 , 10 , 78 , 7 , 43 , 43 ,
43 , 8 , 14 , 65 , 8 , 43 , 74 , 7 , 84 , 69 ,
90 , 43 , 13 , 7 , 11 , 72 , 72 , 72 , 43 , 72 ,
2007-11-27 18:50:44 +00:00
43 , 14 , 43 , 63 , 74 , 43 , 88 , 43 , 43 , 25 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
43 , 8 , 89 , 7 , 5 , 35 , 36 , 37 , 91 , 43 ,
2007-11-27 18:50:44 +00:00
43 , 71 , 71 , 10 , 13 , 10 , 13 , 48 , 8 , 5 ,
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
8 , 25 , 74 , 8 , 7 , 43 , 43 , 11 , 13 , 11 ,
72 , 72 , 72 , 72 , 76 , 74 , 11 , 11 , 63 , 71 ,
71 , 43 , 63 , 63 , 13 , 8 , 71 , 77 , 43 , 7 ,
74
2006-04-24 17:41:27 +00:00
} ;
# define yyerrok (yyerrstatus = 0)
# define yyclearin (yychar = YYEMPTY)
# define YYEMPTY (-2)
# define YYEOF 0
# define YYACCEPT goto yyacceptlab
# define YYABORT goto yyabortlab
# define YYERROR goto yyerrorlab
/* Like YYERROR except do call yyerror. This remains here temporarily
to ease the transition to the new meaning of YYERROR , for GCC .
Once GCC version 2 has supplanted version 1 , this can go . */
# define YYFAIL goto yyerrlab
# define YYRECOVERING() (!!yyerrstatus)
# define YYBACKUP(Token, Value) \
do \
if ( yychar = = YYEMPTY & & yylen = = 1 ) \
{ \
yychar = ( Token ) ; \
yylval = ( Value ) ; \
yytoken = YYTRANSLATE ( yychar ) ; \
2006-06-18 21:36:24 +00:00
YYPOPSTACK ( 1 ) ; \
2006-04-24 17:41:27 +00:00
goto yybackup ; \
} \
else \
{ \
yyerror ( & yylloc , parseio , YY_ ( " syntax error: cannot back up " ) ) ; \
YYERROR ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# define YYTERROR 1
# define YYERRCODE 256
/* YYLLOC_DEFAULT -- Set CURRENT to span from RHS[1] to RHS[N].
If N is 0 , then set CURRENT to the empty location which ends
the previous symbol : RHS [ 0 ] ( always defined ) . */
# define YYRHSLOC(Rhs, K) ((Rhs)[K])
# ifndef YYLLOC_DEFAULT
# define YYLLOC_DEFAULT(Current, Rhs, N) \
do \
2006-06-18 21:36:24 +00:00
if ( YYID ( N ) ) \
2006-04-24 17:41:27 +00:00
{ \
( Current ) . first_line = YYRHSLOC ( Rhs , 1 ) . first_line ; \
( Current ) . first_column = YYRHSLOC ( Rhs , 1 ) . first_column ; \
( Current ) . last_line = YYRHSLOC ( Rhs , N ) . last_line ; \
( Current ) . last_column = YYRHSLOC ( Rhs , N ) . last_column ; \
} \
else \
{ \
( Current ) . first_line = ( Current ) . last_line = \
YYRHSLOC ( Rhs , 0 ) . last_line ; \
( Current ) . first_column = ( Current ) . last_column = \
YYRHSLOC ( Rhs , 0 ) . last_column ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# endif
/* YY_LOCATION_PRINT -- Print the location on the stream.
This macro was not mandated originally : define only if we know
we won ' t break user code : when these are the locations we know . */
# ifndef YY_LOCATION_PRINT
# if YYLTYPE_IS_TRIVIAL
# define YY_LOCATION_PRINT(File, Loc) \
fprintf ( File , " %d.%d-%d.%d " , \
2006-06-18 21:36:24 +00:00
( Loc ) . first_line , ( Loc ) . first_column , \
( Loc ) . last_line , ( Loc ) . last_column )
2006-04-24 17:41:27 +00:00
# else
# define YY_LOCATION_PRINT(File, Loc) ((void) 0)
# endif
# endif
/* YYLEX -- calling `yylex' with the right arguments. */
# ifdef YYLEX_PARAM
# define YYLEX yylex (&yylval, &yylloc, YYLEX_PARAM)
# else
# define YYLEX yylex (&yylval, &yylloc)
# endif
/* Enable debugging if requested. */
# if YYDEBUG
# ifndef YYFPRINTF
# include <stdio.h> /* INFRINGES ON USER NAME SPACE */
# define YYFPRINTF fprintf
# endif
# define YYDPRINTF(Args) \
do { \
if ( yydebug ) \
YYFPRINTF Args ; \
2006-06-18 21:36:24 +00:00
} while ( YYID ( 0 ) )
# define YY_SYMBOL_PRINT(Title, Type, Value, Location) \
do { \
if ( yydebug ) \
{ \
YYFPRINTF ( stderr , " %s " , Title ) ; \
yy_symbol_print ( stderr , \
Type , Value , Location , parseio ) ; \
YYFPRINTF ( stderr , " \n " ) ; \
} \
} while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
/*--------------------------------.
| Print this symbol on YYOUTPUT . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/*ARGSUSED*/
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
static void
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
2008-08-19 15:59:12 +00:00
yy_symbol_value_print ( FILE * yyoutput , int yytype , YYSTYPE const * const yyvaluep , YYLTYPE const * const yylocationp , struct parse_io * parseio )
2006-06-18 21:36:24 +00:00
# else
static void
yy_symbol_value_print ( yyoutput , yytype , yyvaluep , yylocationp , parseio )
FILE * yyoutput ;
int yytype ;
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
2008-08-19 15:59:12 +00:00
YYSTYPE const * const yyvaluep ;
YYLTYPE const * const yylocationp ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
# endif
{
if ( ! yyvaluep )
return ;
YYUSE ( yylocationp ) ;
YYUSE ( parseio ) ;
# ifdef YYPRINT
if ( yytype < YYNTOKENS )
YYPRINT ( yyoutput , yytoknum [ yytype ] , * yyvaluep ) ;
# else
YYUSE ( yyoutput ) ;
# endif
switch ( yytype )
{
default :
break ;
}
}
/*--------------------------------.
| Print this symbol on YYOUTPUT . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
static void
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
2008-08-19 15:59:12 +00:00
yy_symbol_print ( FILE * yyoutput , int yytype , YYSTYPE const * const yyvaluep , YYLTYPE const * const yylocationp , struct parse_io * parseio )
2006-06-18 21:36:24 +00:00
# else
static void
yy_symbol_print ( yyoutput , yytype , yyvaluep , yylocationp , parseio )
FILE * yyoutput ;
int yytype ;
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
2008-08-19 15:59:12 +00:00
YYSTYPE const * const yyvaluep ;
YYLTYPE const * const yylocationp ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
# endif
{
if ( yytype < YYNTOKENS )
YYFPRINTF ( yyoutput , " token %s ( " , yytname [ yytype ] ) ;
else
YYFPRINTF ( yyoutput , " nterm %s ( " , yytname [ yytype ] ) ;
YY_LOCATION_PRINT ( yyoutput , * yylocationp ) ;
YYFPRINTF ( yyoutput , " : " ) ;
yy_symbol_value_print ( yyoutput , yytype , yyvaluep , yylocationp , parseio ) ;
YYFPRINTF ( yyoutput , " ) " ) ;
}
2006-04-24 17:41:27 +00:00
/*------------------------------------------------------------------.
| yy_stack_print - - Print the state stack from its BOTTOM up to its |
| TOP ( included ) . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static void
2006-06-18 21:36:24 +00:00
yy_stack_print ( yytype_int16 * bottom , yytype_int16 * top )
2006-04-24 17:41:27 +00:00
# else
static void
yy_stack_print ( bottom , top )
2006-06-18 21:36:24 +00:00
yytype_int16 * bottom ;
yytype_int16 * top ;
2006-04-24 17:41:27 +00:00
# endif
{
YYFPRINTF ( stderr , " Stack now " ) ;
2006-06-18 21:36:24 +00:00
for ( ; bottom < = top ; + + bottom )
2006-04-24 17:41:27 +00:00
YYFPRINTF ( stderr , " %d " , * bottom ) ;
YYFPRINTF ( stderr , " \n " ) ;
}
# define YY_STACK_PRINT(Bottom, Top) \
do { \
if ( yydebug ) \
yy_stack_print ( ( Bottom ) , ( Top ) ) ; \
2006-06-18 21:36:24 +00:00
} while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
/*------------------------------------------------.
| Report that the YYRULE is going to be reduced . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static void
2006-06-18 21:36:24 +00:00
yy_reduce_print ( YYSTYPE * yyvsp , YYLTYPE * yylsp , int yyrule , struct parse_io * parseio )
2006-04-24 17:41:27 +00:00
# else
static void
2006-06-18 21:36:24 +00:00
yy_reduce_print ( yyvsp , yylsp , yyrule , parseio )
YYSTYPE * yyvsp ;
YYLTYPE * yylsp ;
2006-04-24 17:41:27 +00:00
int yyrule ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
2006-04-24 17:41:27 +00:00
# endif
{
2006-06-18 21:36:24 +00:00
int yynrhs = yyr2 [ yyrule ] ;
2006-04-24 17:41:27 +00:00
int yyi ;
unsigned long int yylno = yyrline [ yyrule ] ;
2006-06-18 21:36:24 +00:00
YYFPRINTF ( stderr , " Reducing stack by rule %d (line %lu): \n " ,
yyrule - 1 , yylno ) ;
/* The symbols being reduced. */
for ( yyi = 0 ; yyi < yynrhs ; yyi + + )
{
fprintf ( stderr , " $%d = " , yyi + 1 ) ;
yy_symbol_print ( stderr , yyrhs [ yyprhs [ yyrule ] + yyi ] ,
& ( yyvsp [ ( yyi + 1 ) - ( yynrhs ) ] )
, & ( yylsp [ ( yyi + 1 ) - ( yynrhs ) ] ) , parseio ) ;
fprintf ( stderr , " \n " ) ;
}
2006-04-24 17:41:27 +00:00
}
# define YY_REDUCE_PRINT(Rule) \
do { \
if ( yydebug ) \
2006-06-18 21:36:24 +00:00
yy_reduce_print ( yyvsp , yylsp , Rule , parseio ) ; \
} while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
/* Nonzero means print parse trace. It is left uninitialized so that
multiple parsers can coexist . */
int yydebug ;
# else /* !YYDEBUG */
# define YYDPRINTF(Args)
# define YY_SYMBOL_PRINT(Title, Type, Value, Location)
# define YY_STACK_PRINT(Bottom, Top)
# define YY_REDUCE_PRINT(Rule)
# endif /* !YYDEBUG */
/* YYINITDEPTH -- initial size of the parser's stacks. */
# ifndef YYINITDEPTH
# define YYINITDEPTH 200
# endif
/* YYMAXDEPTH -- maximum size the stacks can grow to (effective only
if the built - in stack extension method is used ) .
Do not make this value too large ; the results are undefined if
YYSTACK_ALLOC_MAXIMUM < YYSTACK_BYTES ( YYMAXDEPTH )
evaluated with infinite - precision integer arithmetic . */
# ifndef YYMAXDEPTH
# define YYMAXDEPTH 10000
# endif
# if YYERROR_VERBOSE
# ifndef yystrlen
2006-06-18 21:36:24 +00:00
# if defined __GLIBC__ && defined _STRING_H
2006-04-24 17:41:27 +00:00
# define yystrlen strlen
# else
/* Return the length of YYSTR. */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static YYSIZE_T
yystrlen ( const char * yystr )
2006-06-18 21:36:24 +00:00
# else
static YYSIZE_T
2006-04-24 17:41:27 +00:00
yystrlen ( yystr )
2006-06-18 21:36:24 +00:00
const char * yystr ;
# endif
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
YYSIZE_T yylen ;
for ( yylen = 0 ; yystr [ yylen ] ; yylen + + )
2006-04-24 17:41:27 +00:00
continue ;
2006-06-18 21:36:24 +00:00
return yylen ;
2006-04-24 17:41:27 +00:00
}
# endif
# endif
# ifndef yystpcpy
2006-06-18 21:36:24 +00:00
# if defined __GLIBC__ && defined _STRING_H && defined _GNU_SOURCE
2006-04-24 17:41:27 +00:00
# define yystpcpy stpcpy
# else
/* Copy YYSRC to YYDEST, returning the address of the terminating '\0' in
YYDEST . */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static char *
yystpcpy ( char * yydest , const char * yysrc )
2006-06-18 21:36:24 +00:00
# else
static char *
2006-04-24 17:41:27 +00:00
yystpcpy ( yydest , yysrc )
2006-06-18 21:36:24 +00:00
char * yydest ;
const char * yysrc ;
# endif
2006-04-24 17:41:27 +00:00
{
char * yyd = yydest ;
const char * yys = yysrc ;
while ( ( * yyd + + = * yys + + ) ! = ' \0 ' )
continue ;
return yyd - 1 ;
}
# endif
# endif
# ifndef yytnamerr
/* Copy to YYRES the contents of YYSTR after stripping away unnecessary
quotes and backslashes , so that it ' s suitable for yyerror . The
heuristic is that double - quoting is unnecessary unless the string
contains an apostrophe , a comma , or backslash ( other than
backslash - backslash ) . YYSTR is taken from yytname . If YYRES is
null , do not copy ; instead , return the length of what the result
would have been . */
static YYSIZE_T
yytnamerr ( char * yyres , const char * yystr )
{
if ( * yystr = = ' " ' )
{
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
2008-08-19 15:59:12 +00:00
YYSIZE_T yyn = 0 ;
2006-04-24 17:41:27 +00:00
char const * yyp = yystr ;
for ( ; ; )
switch ( * + + yyp )
{
case ' \' ' :
case ' , ' :
goto do_not_strip_quotes ;
case ' \\ ' :
if ( * + + yyp ! = ' \\ ' )
goto do_not_strip_quotes ;
/* Fall through. */
default :
if ( yyres )
yyres [ yyn ] = * yyp ;
yyn + + ;
break ;
case ' " ' :
if ( yyres )
yyres [ yyn ] = ' \0 ' ;
return yyn ;
}
do_not_strip_quotes : ;
}
if ( ! yyres )
return yystrlen ( yystr ) ;
return yystpcpy ( yyres , yystr ) - yyres ;
}
# endif
2006-06-18 21:36:24 +00:00
/* Copy into YYRESULT an error message about the unexpected token
YYCHAR while in state YYSTATE . Return the number of bytes copied ,
including the terminating null byte . If YYRESULT is null , do not
copy anything ; just return the number of bytes that would be
copied . As a special case , return 0 if an ordinary " syntax error "
message will do . Return YYSIZE_MAXIMUM if overflow occurs during
size calculation . */
static YYSIZE_T
yysyntax_error ( char * yyresult , int yystate , int yychar )
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
int yyn = yypact [ yystate ] ;
2006-04-24 17:41:27 +00:00
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
2008-08-19 15:59:12 +00:00
if ( ! ( YYPACT_NINF < yyn & & yyn < = YYLAST ) )
2006-06-18 21:36:24 +00:00
return 0 ;
2006-04-24 17:41:27 +00:00
else
2006-06-18 21:36:24 +00:00
{
int yytype = YYTRANSLATE ( yychar ) ;
YYSIZE_T yysize0 = yytnamerr ( 0 , yytname [ yytype ] ) ;
YYSIZE_T yysize = yysize0 ;
YYSIZE_T yysize1 ;
int yysize_overflow = 0 ;
enum { YYERROR_VERBOSE_ARGS_MAXIMUM = 5 } ;
char const * yyarg [ YYERROR_VERBOSE_ARGS_MAXIMUM ] ;
int yyx ;
# if 0
/* This is so xgettext sees the translatable formats that are
constructed on the fly . */
YY_ ( " syntax error, unexpected %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s or %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s or %s or %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s or %s or %s or %s " ) ;
# endif
char * yyfmt ;
char const * yyf ;
static char const yyunexpected [ ] = " syntax error, unexpected %s " ;
static char const yyexpecting [ ] = " , expecting %s " ;
static char const yyor [ ] = " or %s " ;
char yyformat [ sizeof yyunexpected
+ sizeof yyexpecting - 1
+ ( ( YYERROR_VERBOSE_ARGS_MAXIMUM - 2 )
* ( sizeof yyor - 1 ) ) ] ;
char const * yyprefix = yyexpecting ;
/* Start YYX at -YYN if negative to avoid negative indexes in
YYCHECK . */
int yyxbegin = yyn < 0 ? - yyn : 0 ;
/* Stay within bounds of both yycheck and yytname. */
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
2008-08-19 15:59:12 +00:00
int yychecklim = YYLAST - yyn + 1 ;
2006-06-18 21:36:24 +00:00
int yyxend = yychecklim < YYNTOKENS ? yychecklim : YYNTOKENS ;
int yycount = 1 ;
yyarg [ 0 ] = yytname [ yytype ] ;
yyfmt = yystpcpy ( yyformat , yyunexpected ) ;
for ( yyx = yyxbegin ; yyx < yyxend ; + + yyx )
if ( yycheck [ yyx + yyn ] = = yyx & & yyx ! = YYTERROR )
{
if ( yycount = = YYERROR_VERBOSE_ARGS_MAXIMUM )
{
yycount = 1 ;
yysize = yysize0 ;
yyformat [ sizeof yyunexpected - 1 ] = ' \0 ' ;
break ;
}
yyarg [ yycount + + ] = yytname [ yyx ] ;
yysize1 = yysize + yytnamerr ( 0 , yytname [ yyx ] ) ;
yysize_overflow | = ( yysize1 < yysize ) ;
yysize = yysize1 ;
yyfmt = yystpcpy ( yyfmt , yyprefix ) ;
yyprefix = yyor ;
}
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
yyf = YY_ ( yyformat ) ;
yysize1 = yysize + yystrlen ( yyf ) ;
yysize_overflow | = ( yysize1 < yysize ) ;
yysize = yysize1 ;
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
if ( yysize_overflow )
return YYSIZE_MAXIMUM ;
if ( yyresult )
{
/* Avoid sprintf, as that infringes on the user's name space.
Don ' t have undefined behavior even if the translation
produced a string with the wrong number of " %s " s . */
char * yyp = yyresult ;
int yyi = 0 ;
while ( ( * yyp = * yyf ) ! = ' \0 ' )
{
if ( * yyp = = ' % ' & & yyf [ 1 ] = = ' s ' & & yyi < yycount )
{
yyp + = yytnamerr ( yyp , yyarg [ yyi + + ] ) ;
yyf + = 2 ;
}
else
{
yyp + + ;
yyf + + ;
}
}
}
return yysize ;
2006-04-24 17:41:27 +00:00
}
}
2006-06-18 21:36:24 +00:00
# endif /* YYERROR_VERBOSE */
2006-04-24 17:41:27 +00:00
/*-----------------------------------------------.
| Release the memory associated to this symbol . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
2006-06-18 21:36:24 +00:00
/*ARGSUSED*/
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static void
2006-06-18 21:36:24 +00:00
yydestruct ( const char * yymsg , int yytype , YYSTYPE * yyvaluep , YYLTYPE * yylocationp , struct parse_io * parseio )
2006-04-24 17:41:27 +00:00
# else
static void
2006-06-18 21:36:24 +00:00
yydestruct ( yymsg , yytype , yyvaluep , yylocationp , parseio )
2006-04-24 17:41:27 +00:00
const char * yymsg ;
int yytype ;
YYSTYPE * yyvaluep ;
YYLTYPE * yylocationp ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
2006-04-24 17:41:27 +00:00
# endif
{
2006-06-18 21:36:24 +00:00
YYUSE ( yyvaluep ) ;
YYUSE ( yylocationp ) ;
YYUSE ( parseio ) ;
2006-04-24 17:41:27 +00:00
if ( ! yymsg )
yymsg = " Deleting " ;
YY_SYMBOL_PRINT ( yymsg , yytype , yyvaluep , yylocationp ) ;
switch ( yytype )
{
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
2007-10-26 17:39:39 +00:00
case 43 : /* "word" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1483 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 46 : /* "objects" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1491 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 47 : /* "object" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1499 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 48 : /* "context_name" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1504 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 49 : /* "context" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1512 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 51 : /* "macro" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1520 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 52 : /* "globals" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1528 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 53 : /* "global_statements" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1536 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 54 : /* "assignment" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1544 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 56 : /* "local_assignment" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-30 12:30:08 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1552 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 58 : /* "arglist" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1560 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 59 : /* "elements" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1568 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 60 : /* "element" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1576 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 61 : /* "ignorepat" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1584 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 62 : /* "extension" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1592 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 63 : /* "statements" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1600 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 64 : /* "timerange" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1605 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 65 : /* "timespec" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-02 18:33:15 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1613 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 66 : /* "test_expr" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1618 "ael.tab.c"
2007-06-20 20:10:19 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 68 : /* "if_like_head" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2007-06-20 20:10:19 +00:00
{
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1626 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 69 : /* "word_list" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1631 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 71 : /* "word3_list" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2007-06-20 20:10:19 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1636 "ael.tab.c"
2007-06-20 20:10:19 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 72 : /* "goto_word" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
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
2007-10-26 17:39:39 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1641 "ael.tab.c"
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
2007-10-26 17:39:39 +00:00
break ;
case 73 : /* "switch_statement" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-02 18:23:41 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1649 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 74 : /* "statement" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1657 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 79 : /* "opt_else" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1665 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 80 : /* "target" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1673 "ael.tab.c"
2006-08-12 19:28:33 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 81 : /* "opt_pri" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2006-08-12 19:28:33 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1678 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 82 : /* "jumptarget" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1686 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 83 : /* "macro_call" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1694 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 85 : /* "application_call_head" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1702 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 87 : /* "application_call" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1710 "ael.tab.c"
2006-08-12 19:28:33 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 88 : /* "opt_word" */
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
2008-09-03 14:01:27 +00:00
# line 183 "ael.y"
2006-08-12 19:28:33 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1715 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 89 : /* "eval_arglist" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-03 16:12:31 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1723 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 90 : /* "case_statements" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-03 16:12:31 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1731 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 91 : /* "case_statement" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1739 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 92 : /* "macro_statements" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-30 12:44:54 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1747 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 93 : /* "macro_statement" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1755 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 94 : /* "switches" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1763 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 95 : /* "eswitches" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1771 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 96 : /* "switchlist" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1779 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 97 : /* "included_entry" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1787 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 98 : /* "includeslist" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1795 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 99 : /* "includes" */
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
2008-09-03 14:01:27 +00:00
# line 170 "ael.y"
2006-08-12 19:28:33 +00:00
{
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 1803 "ael.tab.c"
2006-08-12 19:28:33 +00:00
break ;
2006-04-24 17:41:27 +00:00
default :
2006-06-18 21:36:24 +00:00
break ;
2006-04-24 17:41:27 +00:00
}
}
/* Prevent warnings from -Wmissing-prototypes. */
# ifdef YYPARSE_PARAM
2006-06-18 21:36:24 +00:00
# if defined __STDC__ || defined __cplusplus
2006-04-24 17:41:27 +00:00
int yyparse ( void * YYPARSE_PARAM ) ;
2006-06-18 21:36:24 +00:00
# else
2006-04-24 17:41:27 +00:00
int yyparse ( ) ;
2006-06-18 21:36:24 +00:00
# endif
2006-04-24 17:41:27 +00:00
# else /* ! YYPARSE_PARAM */
2006-06-18 21:36:24 +00:00
# if defined __STDC__ || defined __cplusplus
2006-04-24 17:41:27 +00:00
int yyparse ( struct parse_io * parseio ) ;
# else
int yyparse ( ) ;
# endif
# endif /* ! YYPARSE_PARAM */
/*----------.
| yyparse . |
` - - - - - - - - - - */
# ifdef YYPARSE_PARAM
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
int
yyparse ( void * YYPARSE_PARAM )
# else
int
yyparse ( YYPARSE_PARAM )
void * YYPARSE_PARAM ;
# endif
2006-04-24 17:41:27 +00:00
# else /* ! YYPARSE_PARAM */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
int
yyparse ( struct parse_io * parseio )
# else
int
yyparse ( parseio )
struct parse_io * parseio ;
# endif
# endif
{
/* The look-ahead symbol. */
int yychar ;
/* The semantic value of the look-ahead symbol. */
YYSTYPE yylval ;
/* Number of syntax errors so far. */
int yynerrs ;
/* Location data for the look-ahead symbol. */
YYLTYPE yylloc ;
int yystate ;
int yyn ;
int yyresult ;
/* Number of tokens to shift before error messages enabled. */
int yyerrstatus ;
/* Look-ahead token as an internal (translated) token number. */
int yytoken = 0 ;
2006-06-18 21:36:24 +00:00
# if YYERROR_VERBOSE
/* Buffer for error messages, and its allocated size. */
char yymsgbuf [ 128 ] ;
char * yymsg = yymsgbuf ;
YYSIZE_T yymsg_alloc = sizeof yymsgbuf ;
# endif
2006-04-24 17:41:27 +00:00
/* Three stacks and their tools:
` yyss ' : related to states ,
` yyvs ' : related to semantic values ,
` yyls ' : related to locations .
Refer to the stacks thru separate pointers , to allow yyoverflow
to reallocate them elsewhere . */
/* The state stack. */
2006-06-18 21:36:24 +00:00
yytype_int16 yyssa [ YYINITDEPTH ] ;
yytype_int16 * yyss = yyssa ;
yytype_int16 * yyssp ;
2006-04-24 17:41:27 +00:00
/* The semantic value stack. */
YYSTYPE yyvsa [ YYINITDEPTH ] ;
YYSTYPE * yyvs = yyvsa ;
YYSTYPE * yyvsp ;
/* The location stack. */
YYLTYPE yylsa [ YYINITDEPTH ] ;
YYLTYPE * yyls = yylsa ;
YYLTYPE * yylsp ;
2006-06-18 21:36:24 +00:00
/* The locations where the error started and ended. */
2006-04-24 17:41:27 +00:00
YYLTYPE yyerror_range [ 2 ] ;
2006-06-18 21:36:24 +00:00
# define YYPOPSTACK(N) (yyvsp -= (N), yyssp -= (N), yylsp -= (N))
2006-04-24 17:41:27 +00:00
YYSIZE_T yystacksize = YYINITDEPTH ;
/* The variables used to return semantic value and location from the
action routines . */
YYSTYPE yyval ;
YYLTYPE yyloc ;
2006-06-18 21:36:24 +00:00
/* The number of symbols on the RHS of the reduced rule.
Keep to zero when no symbol should be popped . */
int yylen = 0 ;
2006-04-24 17:41:27 +00:00
YYDPRINTF ( ( stderr , " Starting parse \n " ) ) ;
yystate = 0 ;
yyerrstatus = 0 ;
yynerrs = 0 ;
yychar = YYEMPTY ; /* Cause a token to be read. */
/* Initialize stack pointers.
Waste one element of value and location stack
so that they stay on the same level as the state stack .
The wasted elements are never initialized . */
yyssp = yyss ;
yyvsp = yyvs ;
yylsp = yyls ;
# if YYLTYPE_IS_TRIVIAL
/* Initialize the default location before parsing starts. */
yylloc . first_line = yylloc . last_line = 1 ;
yylloc . first_column = yylloc . last_column = 0 ;
# endif
goto yysetstate ;
/*------------------------------------------------------------.
| yynewstate - - Push a new state , which is found in yystate . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yynewstate :
/* In all cases, when you get here, the value and location stacks
2006-06-18 21:36:24 +00:00
have just been pushed . So pushing a state here evens the stacks . */
2006-04-24 17:41:27 +00:00
yyssp + + ;
yysetstate :
* yyssp = yystate ;
if ( yyss + yystacksize - 1 < = yyssp )
{
/* Get the current used size of the three stacks, in elements. */
YYSIZE_T yysize = yyssp - yyss + 1 ;
# ifdef yyoverflow
{
2006-06-18 21:36:24 +00:00
/* Give user a chance to reallocate the stack. Use copies of
2006-04-24 17:41:27 +00:00
these so that the & ' s don ' t force the real ones into
memory . */
YYSTYPE * yyvs1 = yyvs ;
2006-06-18 21:36:24 +00:00
yytype_int16 * yyss1 = yyss ;
2006-04-24 17:41:27 +00:00
YYLTYPE * yyls1 = yyls ;
/* Each stack pointer address is followed by the size of the
data in use in that stack , in bytes . This used to be a
conditional around just the two extra args , but that might
be undefined if yyoverflow is a macro . */
yyoverflow ( YY_ ( " memory exhausted " ) ,
& yyss1 , yysize * sizeof ( * yyssp ) ,
& yyvs1 , yysize * sizeof ( * yyvsp ) ,
& yyls1 , yysize * sizeof ( * yylsp ) ,
& yystacksize ) ;
yyls = yyls1 ;
yyss = yyss1 ;
yyvs = yyvs1 ;
}
# else /* no yyoverflow */
# ifndef YYSTACK_RELOCATE
goto yyexhaustedlab ;
# else
/* Extend the stack our own way. */
if ( YYMAXDEPTH < = yystacksize )
goto yyexhaustedlab ;
yystacksize * = 2 ;
if ( YYMAXDEPTH < yystacksize )
yystacksize = YYMAXDEPTH ;
{
2006-06-18 21:36:24 +00:00
yytype_int16 * yyss1 = yyss ;
2006-04-24 17:41:27 +00:00
union yyalloc * yyptr =
( union yyalloc * ) YYSTACK_ALLOC ( YYSTACK_BYTES ( yystacksize ) ) ;
if ( ! yyptr )
goto yyexhaustedlab ;
YYSTACK_RELOCATE ( yyss ) ;
YYSTACK_RELOCATE ( yyvs ) ;
YYSTACK_RELOCATE ( yyls ) ;
# undef YYSTACK_RELOCATE
if ( yyss1 ! = yyssa )
YYSTACK_FREE ( yyss1 ) ;
}
# endif
# endif /* no yyoverflow */
yyssp = yyss + yysize - 1 ;
yyvsp = yyvs + yysize - 1 ;
yylsp = yyls + yysize - 1 ;
YYDPRINTF ( ( stderr , " Stack size increased to %lu \n " ,
( unsigned long int ) yystacksize ) ) ;
if ( yyss + yystacksize - 1 < = yyssp )
YYABORT ;
}
YYDPRINTF ( ( stderr , " Entering state %d \n " , yystate ) ) ;
goto yybackup ;
/*-----------.
| yybackup . |
` - - - - - - - - - - - */
yybackup :
2006-06-18 21:36:24 +00:00
/* Do appropriate processing given the current state. Read a
look - ahead token if we need one and don ' t already have one . */
2006-04-24 17:41:27 +00:00
/* First try to decide what to do without reference to look-ahead token. */
yyn = yypact [ yystate ] ;
if ( yyn = = YYPACT_NINF )
goto yydefault ;
/* Not known => get a look-ahead token if don't already have one. */
/* YYCHAR is either YYEMPTY or YYEOF or a valid look-ahead symbol. */
if ( yychar = = YYEMPTY )
{
YYDPRINTF ( ( stderr , " Reading a token: " ) ) ;
yychar = YYLEX ;
}
if ( yychar < = YYEOF )
{
yychar = yytoken = YYEOF ;
YYDPRINTF ( ( stderr , " Now at end of input. \n " ) ) ;
}
else
{
yytoken = YYTRANSLATE ( yychar ) ;
YY_SYMBOL_PRINT ( " Next token is " , yytoken , & yylval , & yylloc ) ;
}
/* If the proper action on seeing token YYTOKEN is to reduce or to
detect an error , take that action . */
yyn + = yytoken ;
if ( yyn < 0 | | YYLAST < yyn | | yycheck [ yyn ] ! = yytoken )
goto yydefault ;
yyn = yytable [ yyn ] ;
if ( yyn < = 0 )
{
if ( yyn = = 0 | | yyn = = YYTABLE_NINF )
goto yyerrlab ;
yyn = - yyn ;
goto yyreduce ;
}
if ( yyn = = YYFINAL )
YYACCEPT ;
2006-06-18 21:36:24 +00:00
/* Count tokens shifted since error; after three, turn off error
status . */
if ( yyerrstatus )
yyerrstatus - - ;
2006-04-24 17:41:27 +00:00
/* Shift the look-ahead token. */
YY_SYMBOL_PRINT ( " Shifting " , yytoken , & yylval , & yylloc ) ;
2006-06-18 21:36:24 +00:00
/* Discard the shifted token unless it is eof. */
2006-04-24 17:41:27 +00:00
if ( yychar ! = YYEOF )
yychar = YYEMPTY ;
2006-06-18 21:36:24 +00:00
yystate = yyn ;
2006-04-24 17:41:27 +00:00
* + + yyvsp = yylval ;
* + + yylsp = yylloc ;
goto yynewstate ;
/*-----------------------------------------------------------.
| yydefault - - do the default action for the current state . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yydefault :
yyn = yydefact [ yystate ] ;
if ( yyn = = 0 )
goto yyerrlab ;
goto yyreduce ;
/*-----------------------------.
| yyreduce - - Do a reduction . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyreduce :
/* yyn is the number of a rule to reduce with. */
yylen = yyr2 [ yyn ] ;
/* If YYLEN is nonzero, implement the default value of the action:
` $ $ = $ 1 ' .
Otherwise , the following line sets YYVAL to garbage .
This behavior is undocumented and Bison
users should not rely upon it . Assigning to YYVAL
unconditionally makes the parser a bit smaller , and it avoids a
GCC warning that YYVAL may be used uninitialized . */
yyval = yyvsp [ 1 - yylen ] ;
2006-06-18 21:36:24 +00:00
/* Default location. */
YYLLOC_DEFAULT ( yyloc , ( yylsp - yylen ) , yylen ) ;
2006-04-24 17:41:27 +00:00
YY_REDUCE_PRINT ( yyn ) ;
switch ( yyn )
{
case 2 :
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
2008-09-03 14:01:27 +00:00
# line 191 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = parseio - > pval = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 3 :
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
2008-09-03 14:01:27 +00:00
# line 194 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 4 :
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
2008-09-03 14:01:27 +00:00
# line 195 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 5 :
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
2008-09-03 14:01:27 +00:00
# line 196 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 6 :
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
2008-09-03 14:01:27 +00:00
# line 199 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 7 :
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
2008-09-03 14:01:27 +00:00
# line 200 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 8 :
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
2008-09-03 14:01:27 +00:00
# line 201 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 9 :
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
2008-09-03 14:01:27 +00:00
# line 202 "ael.y"
2006-04-24 17:41:27 +00:00
{ ( yyval . pval ) = 0 ; /* allow older docs to be read */ ; }
break ;
case 10 :
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
2008-09-03 14:01:27 +00:00
# line 205 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 11 :
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
2008-09-03 14:01:27 +00:00
# line 206 "ael.y"
2006-04-30 08:21:46 +00:00
{ ( yyval . str ) = strdup ( " default " ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 12 :
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
2008-09-03 14:01:27 +00:00
# line 209 "ael.y"
2006-04-27 02:00:35 +00:00
{
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
2007-10-26 17:39:39 +00:00
( yyval . pval ) = npval2 ( PV_CONTEXT , & ( yylsp [ ( 1 ) - ( 6 ) ] ) , & ( yylsp [ ( 6 ) - ( 6 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 3 ) - ( 6 ) ] . str ) ;
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 5 ) - ( 6 ) ] . pval ) ;
set_dads ( ( yyval . pval ) , ( yyvsp [ ( 5 ) - ( 6 ) ] . pval ) ) ;
( yyval . pval ) - > u3 . abstract = ( yyvsp [ ( 1 ) - ( 6 ) ] . intval ) ; ; }
2006-04-30 12:44:54 +00:00
break ;
case 13 :
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
2008-09-03 14:01:27 +00:00
# line 218 "ael.y"
2006-04-30 12:44:54 +00:00
{ ( yyval . intval ) = 1 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2006-04-30 12:30:08 +00:00
case 14 :
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
2008-09-03 14:01:27 +00:00
# line 219 "ael.y"
2006-04-30 12:44:54 +00:00
{ ( yyval . intval ) = 0 ; ; }
break ;
case 15 :
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
2008-09-03 14:01:27 +00:00
# line 220 "ael.y"
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
2007-10-26 17:39:39 +00:00
{ ( yyval . intval ) = 2 ; ; }
break ;
case 16 :
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
2008-09-03 14:01:27 +00:00
# line 221 "ael.y"
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
2007-10-26 17:39:39 +00:00
{ ( yyval . intval ) = 3 ; ; }
break ;
case 17 :
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
2008-09-03 14:01:27 +00:00
# line 222 "ael.y"
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
2007-10-26 17:39:39 +00:00
{ ( yyval . intval ) = 3 ; ; }
break ;
case 18 :
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
2008-09-03 14:01:27 +00:00
# line 225 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_MACRO , & ( yylsp [ ( 1 ) - ( 8 ) ] ) , & ( yylsp [ ( 8 ) - ( 8 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 8 ) ] . str ) ; ( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 4 ) - ( 8 ) ] . pval ) ; ( yyval . pval ) - > u3 . macro_statements = ( yyvsp [ ( 7 ) - ( 8 ) ] . pval ) ;
set_dads ( ( yyval . pval ) , ( yyvsp [ ( 7 ) - ( 8 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 19 :
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
2008-09-03 14:01:27 +00:00
# line 231 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_GLOBALS , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . statements = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ;
set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 20 :
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
2008-09-03 14:01:27 +00:00
# line 237 "ael.y"
2006-05-03 16:28:48 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 21 :
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
2008-09-03 14:01:27 +00:00
# line 238 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 22 :
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
2008-09-03 14:01:27 +00:00
# line 239 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 23 :
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
2008-09-03 14:01:27 +00:00
# line 242 "ael.y"
2006-05-02 18:48:47 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 24 :
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
2008-09-03 14:01:27 +00:00
# line 242 "ael.y"
2006-05-02 18:48:47 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_VARDEC , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ;
( yyval . pval ) - > u2 . val = ( yyvsp [ ( 4 ) - ( 5 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 25 :
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
2008-09-03 14:01:27 +00:00
# line 248 "ael.y"
2007-06-20 20:10:19 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 26 :
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
2008-09-03 14:01:27 +00:00
# line 248 "ael.y"
2007-06-20 20:10:19 +00:00
{
( yyval . pval ) = npval2 ( PV_LOCALVARDEC , & ( yylsp [ ( 1 ) - ( 6 ) ] ) , & ( yylsp [ ( 6 ) - ( 6 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 6 ) ] . str ) ;
( yyval . pval ) - > u2 . val = ( yyvsp [ ( 5 ) - ( 6 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 27 :
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
2008-09-03 14:01:27 +00:00
# line 255 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 28 :
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
2008-09-03 14:01:27 +00:00
# line 256 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
2006-05-02 18:51:33 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 29 :
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
2008-09-03 14:01:27 +00:00
# line 257 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ) ; ; }
2006-05-03 16:28:48 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 30 :
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
2008-09-03 14:01:27 +00:00
# line 258 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 31 :
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
2008-09-03 14:01:27 +00:00
# line 261 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = 0 ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 32 :
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
2008-09-03 14:01:27 +00:00
# line 262 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-30 12:30:08 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 33 :
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
2008-09-03 14:01:27 +00:00
# line 263 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-30 12:30:08 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 34 :
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
2008-09-03 14:01:27 +00:00
# line 266 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 35 :
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
2008-09-03 14:01:27 +00:00
# line 267 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 36 :
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
2008-09-03 14:01:27 +00:00
# line 268 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 37 :
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
2008-09-03 14:01:27 +00:00
# line 269 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 38 :
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
2008-09-03 14:01:27 +00:00
# line 270 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 39 :
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
2008-09-03 14:01:27 +00:00
# line 271 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 40 :
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
2008-09-03 14:01:27 +00:00
# line 272 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
break ;
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
2007-10-26 17:39:39 +00:00
case 41 :
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
2008-09-03 14:01:27 +00:00
# line 273 "ael.y"
2007-06-20 20:10:19 +00:00
{ free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ; ( yyval . pval ) = 0 ; ; }
break ;
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
2007-10-26 17:39:39 +00:00
case 42 :
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
2008-09-03 14:01:27 +00:00
# line 274 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = 0 ; /* allow older docs to be read */ ; }
break ;
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
2007-10-26 17:39:39 +00:00
case 43 :
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
2008-09-03 14:01:27 +00:00
# line 277 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_IGNOREPAT , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 3 ) - ( 4 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 44 :
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
2008-09-03 14:01:27 +00:00
# line 282 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2007-10-26 17:39:39 +00:00
case 45 :
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
2008-09-03 14:01:27 +00:00
# line 286 "ael.y"
2007-11-27 18:50:44 +00:00
{
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = malloc ( strlen ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) + strlen ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) + 2 ) ;
strcpy ( ( yyval . pval ) - > u1 . str , ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) ;
strcat ( ( yyval . pval ) - > u1 . str , " @ " ) ;
strcat ( ( yyval . pval ) - > u1 . str , ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) ;
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 5 ) - ( 5 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 5 ) - ( 5 ) ] . pval ) ) ; ; }
break ;
case 46 :
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
2008-09-03 14:01:27 +00:00
# line 294 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ) ;
2006-04-27 02:29:32 +00:00
( yyval . pval ) - > u4 . regexten = 1 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 47 :
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
2008-09-03 14:01:27 +00:00
# line 299 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 7 ) ] ) , & ( yylsp [ ( 7 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 5 ) - ( 7 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 7 ) - ( 7 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 7 ) - ( 7 ) ] . pval ) ) ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u3 . hints = ( yyvsp [ ( 3 ) - ( 7 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 48 :
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
2008-09-03 14:01:27 +00:00
# line 304 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 8 ) ] ) , & ( yylsp [ ( 8 ) - ( 8 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 6 ) - ( 8 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 8 ) - ( 8 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 8 ) - ( 8 ) ] . pval ) ) ;
2006-04-27 02:29:32 +00:00
( yyval . pval ) - > u4 . regexten = 1 ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u3 . hints = ( yyvsp [ ( 4 ) - ( 8 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 49 :
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
2008-09-03 14:01:27 +00:00
# line 313 "ael.y"
2006-05-03 16:33:00 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 50 :
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
2008-09-03 14:01:27 +00:00
# line 314 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 51 :
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
2008-09-03 14:01:27 +00:00
# line 315 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 52 :
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
2008-09-03 14:01:27 +00:00
# line 321 "ael.y"
2006-05-02 18:23:41 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( yyval . str ) , " %s:%s:%s " , ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) ) ;
}
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 53 :
2008-11-02 18:52:13 +00:00
# line 331 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 54 :
2008-11-02 18:52:13 +00:00
# line 335 "ael.y"
2006-05-02 18:33:15 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > next - > next - > next = nword ( ( yyvsp [ ( 7 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 7 ) - ( 7 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 55 :
2008-11-02 18:52:13 +00:00
# line 343 "ael.y"
2006-05-02 18:33:15 +00:00
{ reset_parencount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 56 :
2008-11-02 18:52:13 +00:00
# line 343 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 3 ) - ( 4 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 57 :
2008-11-02 18:52:13 +00:00
# line 347 "ael.y"
2006-05-02 19:17:49 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_IF , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 58 :
2008-11-02 18:52:13 +00:00
# line 350 "ael.y"
2006-05-02 18:23:41 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_RANDOM , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ; ; }
2006-05-02 18:23:41 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 59 :
2008-11-02 18:52:13 +00:00
# line 353 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_IFTIME , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ;
2006-05-02 18:33:15 +00:00
prev_word = 0 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 60 :
2008-11-02 18:52:13 +00:00
# line 364 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 61 :
2008-11-02 18:52:13 +00:00
# line 365 "ael.y"
2006-04-27 08:24:00 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s%s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
prev_word = ( yyval . str ) ;
}
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 62 :
2008-11-02 18:52:13 +00:00
# line 377 "ael.y"
2006-08-12 19:28:33 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 63 :
2008-11-02 18:52:13 +00:00
# line 378 "ael.y"
2006-08-12 19:28:33 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s %s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
}
; }
2006-08-12 19:28:33 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 64 :
2008-11-02 18:52:13 +00:00
# line 387 "ael.y"
2007-10-24 04:44:27 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s:%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
}
; }
2007-10-24 04:44:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 65 :
2008-11-02 18:52:13 +00:00
# line 396 "ael.y"
2006-08-12 19:28:33 +00:00
{ /* there are often '&' in hints */
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s&%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
}
; }
2006-08-12 19:28:33 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 66 :
2008-11-02 18:52:13 +00:00
# line 407 "ael.y"
2006-08-12 19:28:33 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 67 :
2008-11-02 18:52:13 +00:00
# line 408 "ael.y"
2006-04-27 08:24:00 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s%s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
prev_word = ( yyval . str ) ;
}
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 68 :
2008-11-02 18:52:13 +00:00
# line 418 "ael.y"
2006-04-27 08:24:00 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s%s%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
prev_word = ( yyval . str ) ;
}
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 69 :
2008-11-02 18:52:13 +00:00
# line 431 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 70 :
2008-11-02 18:52:13 +00:00
# line 432 "ael.y"
2006-04-27 08:24:00 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s%s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
}
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 71 :
2008-11-02 18:52:13 +00:00
# line 441 "ael.y"
2006-04-27 08:24:00 +00:00
{
2008-11-02 18:52:13 +00:00
if ( asprintf ( & ( ( yyval . str ) ) , " %s:%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) < 0 ) {
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . str ) = NULL ;
} else {
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
}
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 72 :
2008-11-02 18:52:13 +00:00
# line 452 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_SWITCH , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 5 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 73 :
2008-11-02 18:52:13 +00:00
# line 461 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_STATEMENTBLOCK , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 74 :
2008-11-02 18:52:13 +00:00
# line 464 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 75 :
2008-11-02 18:52:13 +00:00
# line 465 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 76 :
2008-11-02 18:52:13 +00:00
# line 466 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_GOTO , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 77 :
2008-11-02 18:52:13 +00:00
# line 469 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_GOTO , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 78 :
2008-11-02 18:52:13 +00:00
# line 472 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_LABEL , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 79 :
2008-11-02 18:52:13 +00:00
# line 475 "ael.y"
2006-05-02 20:13:58 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 80 :
2008-11-02 18:52:13 +00:00
# line 476 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 81 :
2008-11-02 18:52:13 +00:00
# line 477 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_parencount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 82 :
2008-11-02 18:52:13 +00:00
# line 477 "ael.y"
2006-05-02 19:17:49 +00:00
{ /* XXX word_list maybe ? */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_FOR , & ( yylsp [ ( 1 ) - ( 12 ) ] ) , & ( yylsp [ ( 12 ) - ( 12 ) ] ) ) ;
( yyval . pval ) - > u1 . for_init = ( yyvsp [ ( 4 ) - ( 12 ) ] . str ) ;
( yyval . pval ) - > u2 . for_test = ( yyvsp [ ( 7 ) - ( 12 ) ] . str ) ;
( yyval . pval ) - > u3 . for_inc = ( yyvsp [ ( 10 ) - ( 12 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u4 . for_statements = ( yyvsp [ ( 12 ) - ( 12 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 12 ) - ( 12 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 83 :
2008-11-02 18:52:13 +00:00
# line 483 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_WHILE , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 3 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 84 :
2008-11-02 18:52:13 +00:00
# line 487 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 85 :
2008-11-02 18:52:13 +00:00
# line 488 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = update_last ( ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 86 :
2008-11-02 18:52:13 +00:00
# line 489 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 87 :
2008-11-02 18:52:13 +00:00
# line 490 "ael.y"
2006-04-27 08:37:40 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_APPLICATION_CALL , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 88 :
2008-11-02 18:52:13 +00:00
# line 493 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 89 :
2008-11-02 18:52:13 +00:00
# line 493 "ael.y"
2006-04-24 17:41:27 +00:00
{
2006-04-27 08:37:40 +00:00
char * bufx ;
int tot = 0 ;
pval * pptr ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_VARDEC , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u2 . val = ( yyvsp [ ( 4 ) - ( 5 ) ] . str ) ;
2006-04-27 08:37:40 +00:00
/* rebuild the original string-- this is not an app call, it's an unwrapped vardec, with a func call on the LHS */
/* string to big to fit in the buffer? */
2006-06-18 21:36:24 +00:00
tot + = strlen ( ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) ;
for ( pptr = ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u2 . arglist ; pptr ; pptr = pptr - > next ) {
2006-04-27 08:37:40 +00:00
tot + = strlen ( pptr - > u1 . str ) ;
tot + + ; /* for a sep like a comma */
}
tot + = 4 ; /* for safety */
2006-05-02 03:03:27 +00:00
bufx = calloc ( 1 , tot ) ;
2006-06-18 21:36:24 +00:00
strcpy ( bufx , ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) ;
2006-04-27 08:37:40 +00:00
strcat ( bufx , " ( " ) ;
/* XXX need to advance the pointer or the loop is very inefficient */
2006-06-18 21:36:24 +00:00
for ( pptr = ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u2 . arglist ; pptr ; pptr = pptr - > next ) {
if ( pptr ! = ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u2 . arglist )
2006-04-27 08:37:40 +00:00
strcat ( bufx , " , " ) ;
strcat ( bufx , pptr - > u1 . str ) ;
}
strcat ( bufx , " ) " ) ;
2006-04-24 17:41:27 +00:00
# ifdef AAL_ARGCHECK
2006-06-18 21:36:24 +00:00
if ( ! ael_is_funcname ( ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) )
2006-04-27 08:37:40 +00:00
ast_log ( LOG_WARNING , " ==== File: %s, Line %d, Cols: %d-%d: Function call? The name %s is not in my internal list of function names \n " ,
2006-06-18 21:36:24 +00:00
my_file , ( yylsp [ ( 1 ) - ( 5 ) ] ) . first_line , ( yylsp [ ( 1 ) - ( 5 ) ] ) . first_column , ( yylsp [ ( 1 ) - ( 5 ) ] ) . last_column , ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) ;
2006-04-24 17:41:27 +00:00
# endif
2006-04-27 08:37:40 +00:00
( yyval . pval ) - > u1 . str = bufx ;
2006-06-18 21:36:24 +00:00
destroy_pval ( ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) ) ; /* the app call it is not, get rid of that chain */
2006-04-27 08:37:40 +00:00
prev_word = 0 ;
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 90 :
2008-11-02 18:52:13 +00:00
# line 526 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = npval2 ( PV_BREAK , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 91 :
2008-11-02 18:52:13 +00:00
# line 527 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = npval2 ( PV_RETURN , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 92 :
2008-11-02 18:52:13 +00:00
# line 528 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = npval2 ( PV_CONTINUE , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 93 :
2008-11-02 18:52:13 +00:00
# line 529 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ) ;
( yyval . pval ) - > u3 . else_statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 94 :
2008-11-02 18:52:13 +00:00
# line 533 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = 0 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 95 :
2008-11-02 18:52:13 +00:00
# line 536 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 96 :
2008-11-02 18:52:13 +00:00
# line 537 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 97 :
2008-11-02 18:52:13 +00:00
# line 540 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 98 :
2008-11-02 18:52:13 +00:00
# line 541 "ael.y"
2006-04-27 06:44:38 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 99 :
2008-11-02 18:52:13 +00:00
# line 544 "ael.y"
2006-04-27 17:59:09 +00:00
{
2007-10-24 04:44:27 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 100 :
2008-11-02 18:52:13 +00:00
# line 547 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 101 :
2008-11-02 18:52:13 +00:00
# line 551 "ael.y"
2006-04-27 17:59:09 +00:00
{
2007-10-24 04:44:27 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 102 :
2008-11-02 18:52:13 +00:00
# line 555 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( strdup ( " default " ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 103 :
2008-11-02 18:52:13 +00:00
# line 559 "ael.y"
2007-10-24 04:44:27 +00:00
{
( yyval . pval ) = nword ( strdup ( " default " ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 104 :
2008-11-02 18:52:13 +00:00
# line 565 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . str ) = strdup ( " 1 " ) ; ; }
2006-05-03 17:07:56 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 105 :
2008-11-02 18:52:13 +00:00
# line 566 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 106 :
2008-11-02 18:52:13 +00:00
# line 570 "ael.y"
2006-05-03 17:07:56 +00:00
{ /* ext[, pri] default 1 */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 107 :
2008-11-02 18:52:13 +00:00
# line 573 "ael.y"
2006-05-02 20:11:24 +00:00
{ /* context, ext, pri */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 4 ) - ( 4 ) ] . str ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 1 ) - ( 4 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) , & ( yylsp [ ( 2 ) - ( 4 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 108 :
2008-11-02 18:52:13 +00:00
# line 579 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_argcount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 109 :
2008-11-02 18:52:13 +00:00
# line 579 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-04-27 18:18:12 +00:00
/* XXX original code had @2 but i think we need @5 */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_MACRO_CALL , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ;
( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 110 :
2008-11-02 18:52:13 +00:00
# line 584 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_MACRO_CALL , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 111 :
2008-11-02 18:52:13 +00:00
# line 592 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_argcount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 112 :
2008-11-02 18:52:13 +00:00
# line 592 "ael.y"
2006-04-27 08:37:40 +00:00
{
2006-06-18 21:36:24 +00:00
if ( strcasecmp ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , " goto " ) = = 0 ) {
( yyval . pval ) = npval2 ( PV_GOTO , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ; /* won't be using this */
ast_log ( LOG_WARNING , " ==== File: %s, Line %d, Cols: %d-%d: Suggestion: Use the goto statement instead of the Goto() application call in AEL. \n " , my_file , ( yylsp [ ( 1 ) - ( 3 ) ] ) . first_line , ( yylsp [ ( 1 ) - ( 3 ) ] ) . first_column , ( yylsp [ ( 1 ) - ( 3 ) ] ) . last_column ) ;
2006-05-01 00:02:12 +00:00
} else {
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_APPLICATION_CALL , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ;
2006-05-01 00:02:12 +00:00
} ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 113 :
2008-11-02 18:52:13 +00:00
# line 603 "ael.y"
2006-04-30 12:12:39 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
2006-04-24 17:41:27 +00:00
if ( ( yyval . pval ) - > type = = PV_GOTO )
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ;
2006-04-24 17:41:27 +00:00
else
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ;
2006-04-30 12:12:39 +00:00
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 114 :
2008-11-02 18:52:13 +00:00
# line 610 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-05-02 20:13:58 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 115 :
2008-11-02 18:52:13 +00:00
# line 613 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; }
2006-05-02 20:11:24 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 116 :
2008-11-02 18:52:13 +00:00
# line 614 "ael.y"
2006-05-02 20:13:58 +00:00
{ ( yyval . str ) = strdup ( " " ) ; ; }
2006-05-02 18:51:33 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 117 :
2008-11-02 18:52:13 +00:00
# line 617 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 118 :
2008-11-02 18:52:13 +00:00
# line 618 "ael.y"
2006-05-02 20:13:58 +00:00
{
( yyval . pval ) = npval ( PV_WORD , 0 /*@1.first_line*/ , 0 /*@1.last_line*/ , 0 /* @1.first_column*/ , 0 /*@1.last_column*/ ) ;
( yyval . pval ) - > u1 . str = strdup ( " " ) ; ; }
2006-04-30 08:21:46 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 119 :
2008-11-02 18:52:13 +00:00
# line 621 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ) ; ; }
2006-04-30 08:21:46 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 120 :
2008-11-02 18:52:13 +00:00
# line 624 "ael.y"
2006-05-02 20:18:02 +00:00
{ ( yyval . pval ) = NULL ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 121 :
2008-11-02 18:52:13 +00:00
# line 625 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 122 :
2008-11-02 18:52:13 +00:00
# line 628 "ael.y"
2006-04-27 19:14:07 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_CASE , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 3 ) - ( 4 ) ] ) ) ; /* XXX 3 or 4 ? */
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 123 :
2008-11-02 18:52:13 +00:00
# line 632 "ael.y"
2006-04-27 19:14:07 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_DEFAULT , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
2006-05-03 16:12:31 +00:00
( yyval . pval ) - > u1 . str = NULL ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 124 :
2008-11-02 18:52:13 +00:00
# line 636 "ael.y"
2006-04-27 19:14:07 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_PATTERN , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ; /* XXX@3 or @4 ? */
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 125 :
2008-11-02 18:52:13 +00:00
# line 642 "ael.y"
2006-05-02 18:51:33 +00:00
{ ( yyval . pval ) = NULL ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 126 :
2008-11-02 18:52:13 +00:00
# line 643 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 127 :
2008-11-02 18:52:13 +00:00
# line 646 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 128 :
2008-11-02 18:52:13 +00:00
# line 647 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 129 :
2008-11-02 18:52:13 +00:00
# line 648 "ael.y"
2006-04-28 06:26:27 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_CATCH , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 5 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 130 :
2008-11-02 18:52:13 +00:00
# line 654 "ael.y"
2006-04-28 06:26:27 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_SWITCHES , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 2 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 131 :
2008-11-02 18:52:13 +00:00
# line 659 "ael.y"
2006-04-28 11:20:21 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_ESWITCHES , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 2 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 132 :
2008-11-02 18:52:13 +00:00
# line 664 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-30 12:44:54 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 133 :
2008-11-02 18:52:13 +00:00
# line 665 "ael.y"
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , nword ( ( yyvsp [ ( 2 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 134 :
2008-11-02 18:52:13 +00:00
# line 666 "ael.y"
{
char * x ;
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
if ( asprintf ( & x , " %s@%s " , ( yyvsp [ ( 2 ) - ( 5 ) ] . str ) , ( yyvsp [ ( 4 ) - ( 5 ) ] . str ) ) < 0 ) {
2008-11-02 18:52:13 +00:00
ast_log ( LOG_WARNING , " asprintf() failed \n " ) ;
( yyval . pval ) = NULL ;
} else {
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
free ( ( yyvsp [ ( 2 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 4 ) - ( 5 ) ] . str ) ) ;
( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) , nword ( x , & ( yylsp [ ( 2 ) - ( 5 ) ] ) ) ) ;
2008-11-02 18:52:13 +00:00
}
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 135 :
2008-11-02 18:52:13 +00:00
# line 677 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2007-05-03 14:24:00 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 136 :
2008-11-02 18:52:13 +00:00
# line 680 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 137 :
2008-11-02 18:52:13 +00:00
# line 681 "ael.y"
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ;
2006-05-02 18:41:57 +00:00
prev_word = 0 ; /* XXX sure ? */ ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 138 :
2008-11-02 18:52:13 +00:00
# line 688 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 139 :
2008-11-02 18:52:13 +00:00
# line 689 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 140 :
2008-11-02 18:52:13 +00:00
# line 690 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 141 :
2008-11-02 18:52:13 +00:00
# line 693 "ael.y"
2006-04-27 06:44:38 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_INCLUDES , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 142 :
2008-11-02 18:52:13 +00:00
# line 696 "ael.y"
2006-04-27 06:44:38 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_INCLUDES , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
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
2008-08-19 15:59:12 +00:00
/* Line 1267 of yacc.c. */
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
This patch fixes a regression of sorts that was introduced in
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-18 23:50:57 +00:00
# line 3093 "ael.tab.c"
2006-04-24 17:41:27 +00:00
default : break ;
}
2006-06-18 21:36:24 +00:00
YY_SYMBOL_PRINT ( " -> $$ = " , yyr1 [ yyn ] , & yyval , & yyloc ) ;
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
YYPOPSTACK ( yylen ) ;
yylen = 0 ;
2006-04-24 17:41:27 +00:00
YY_STACK_PRINT ( yyss , yyssp ) ;
* + + yyvsp = yyval ;
* + + yylsp = yyloc ;
/* Now `shift' the result of the reduction. Determine what state
that goes to , based on the state we popped back to and the rule
number reduced by . */
yyn = yyr1 [ yyn ] ;
yystate = yypgoto [ yyn - YYNTOKENS ] + * yyssp ;
if ( 0 < = yystate & & yystate < = YYLAST & & yycheck [ yystate ] = = * yyssp )
yystate = yytable [ yystate ] ;
else
yystate = yydefgoto [ yyn - YYNTOKENS ] ;
goto yynewstate ;
/*------------------------------------.
| yyerrlab - - here on detecting error |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyerrlab :
/* If not already recovering from an error, report this error. */
if ( ! yyerrstatus )
{
+ + yynerrs ;
2006-06-18 21:36:24 +00:00
# if ! YYERROR_VERBOSE
yyerror ( & yylloc , parseio , YY_ ( " syntax error " ) ) ;
# else
{
YYSIZE_T yysize = yysyntax_error ( 0 , yystate , yychar ) ;
if ( yymsg_alloc < yysize & & yymsg_alloc < YYSTACK_ALLOC_MAXIMUM )
{
YYSIZE_T yyalloc = 2 * yysize ;
if ( ! ( yysize < = yyalloc & & yyalloc < = YYSTACK_ALLOC_MAXIMUM ) )
yyalloc = YYSTACK_ALLOC_MAXIMUM ;
if ( yymsg ! = yymsgbuf )
YYSTACK_FREE ( yymsg ) ;
yymsg = ( char * ) YYSTACK_ALLOC ( yyalloc ) ;
if ( yymsg )
yymsg_alloc = yyalloc ;
else
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
yymsg = yymsgbuf ;
yymsg_alloc = sizeof yymsgbuf ;
2006-04-24 17:41:27 +00:00
}
2006-06-18 21:36:24 +00:00
}
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
if ( 0 < yysize & & yysize < = yymsg_alloc )
{
( void ) yysyntax_error ( yymsg , yystate , yychar ) ;
yyerror ( & yylloc , parseio , yymsg ) ;
}
else
{
yyerror ( & yylloc , parseio , YY_ ( " syntax error " ) ) ;
if ( yysize ! = 0 )
2006-04-24 17:41:27 +00:00
goto yyexhaustedlab ;
2006-06-18 21:36:24 +00:00
}
}
# endif
2006-04-24 17:41:27 +00:00
}
yyerror_range [ 0 ] = yylloc ;
if ( yyerrstatus = = 3 )
{
/* If just tried and failed to reuse look-ahead token after an
error , discard it . */
if ( yychar < = YYEOF )
2006-06-18 21:36:24 +00:00
{
2006-04-24 17:41:27 +00:00
/* Return failure if at end of input. */
if ( yychar = = YYEOF )
YYABORT ;
2006-06-18 21:36:24 +00:00
}
2006-04-24 17:41:27 +00:00
else
{
2006-06-18 21:36:24 +00:00
yydestruct ( " Error: discarding " ,
yytoken , & yylval , & yylloc , parseio ) ;
2006-04-24 17:41:27 +00:00
yychar = YYEMPTY ;
}
}
/* Else will try to reuse look-ahead token after shifting the error
token . */
goto yyerrlab1 ;
/*---------------------------------------------------.
| yyerrorlab - - error raised explicitly by YYERROR . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyerrorlab :
/* Pacify compilers like GCC when the user code never invokes
YYERROR and the label yyerrorlab therefore never appears in user
code . */
2006-06-18 21:36:24 +00:00
if ( /*CONSTCOND*/ 0 )
2006-04-24 17:41:27 +00:00
goto yyerrorlab ;
yyerror_range [ 0 ] = yylsp [ 1 - yylen ] ;
2006-06-18 21:36:24 +00:00
/* Do not reclaim the symbols of the rule which action triggered
this YYERROR . */
YYPOPSTACK ( yylen ) ;
yylen = 0 ;
YY_STACK_PRINT ( yyss , yyssp ) ;
2006-04-24 17:41:27 +00:00
yystate = * yyssp ;
goto yyerrlab1 ;
/*-------------------------------------------------------------.
| yyerrlab1 - - common code for both syntax error and YYERROR . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyerrlab1 :
yyerrstatus = 3 ; /* Each real token shifted decrements this. */
for ( ; ; )
{
yyn = yypact [ yystate ] ;
if ( yyn ! = YYPACT_NINF )
{
yyn + = YYTERROR ;
if ( 0 < = yyn & & yyn < = YYLAST & & yycheck [ yyn ] = = YYTERROR )
{
yyn = yytable [ yyn ] ;
if ( 0 < yyn )
break ;
}
}
/* Pop the current state because it cannot handle the error token. */
if ( yyssp = = yyss )
YYABORT ;
yyerror_range [ 0 ] = * yylsp ;
2006-06-18 21:36:24 +00:00
yydestruct ( " Error: popping " ,
yystos [ yystate ] , yyvsp , yylsp , parseio ) ;
YYPOPSTACK ( 1 ) ;
2006-04-24 17:41:27 +00:00
yystate = * yyssp ;
YY_STACK_PRINT ( yyss , yyssp ) ;
}
if ( yyn = = YYFINAL )
YYACCEPT ;
* + + yyvsp = yylval ;
yyerror_range [ 1 ] = yylloc ;
/* Using YYLLOC is tempting, but would change the location of
2006-06-18 21:36:24 +00:00
the look - ahead . YYLOC is available though . */
YYLLOC_DEFAULT ( yyloc , ( yyerror_range - 1 ) , 2 ) ;
2006-04-24 17:41:27 +00:00
* + + yylsp = yyloc ;
2006-06-18 21:36:24 +00:00
/* Shift the error token. */
2006-04-24 17:41:27 +00:00
YY_SYMBOL_PRINT ( " Shifting " , yystos [ yyn ] , yyvsp , yylsp ) ;
yystate = yyn ;
goto yynewstate ;
/*-------------------------------------.
| yyacceptlab - - YYACCEPT comes here . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyacceptlab :
yyresult = 0 ;
goto yyreturn ;
/*-----------------------------------.
| yyabortlab - - YYABORT comes here . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyabortlab :
yyresult = 1 ;
goto yyreturn ;
# ifndef yyoverflow
/*-------------------------------------------------.
| yyexhaustedlab - - memory exhaustion comes here . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyexhaustedlab :
yyerror ( & yylloc , parseio , YY_ ( " memory exhausted " ) ) ;
yyresult = 2 ;
/* Fall through. */
# endif
yyreturn :
if ( yychar ! = YYEOF & & yychar ! = YYEMPTY )
yydestruct ( " Cleanup: discarding lookahead " ,
2006-06-18 21:36:24 +00:00
yytoken , & yylval , & yylloc , parseio ) ;
/* Do not reclaim the symbols of the rule which action triggered
this YYABORT or YYACCEPT . */
YYPOPSTACK ( yylen ) ;
YY_STACK_PRINT ( yyss , yyssp ) ;
2006-04-24 17:41:27 +00:00
while ( yyssp ! = yyss )
{
yydestruct ( " Cleanup: popping " ,
2006-06-18 21:36:24 +00:00
yystos [ * yyssp ] , yyvsp , yylsp , parseio ) ;
YYPOPSTACK ( 1 ) ;
2006-04-24 17:41:27 +00:00
}
# ifndef yyoverflow
if ( yyss ! = yyssa )
YYSTACK_FREE ( yyss ) ;
2006-06-18 21:36:24 +00:00
# endif
# if YYERROR_VERBOSE
if ( yymsg ! = yymsgbuf )
YYSTACK_FREE ( yymsg ) ;
2006-04-24 17:41:27 +00:00
# endif
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
2008-08-19 15:59:12 +00:00
/* Make sure YYID is used. */
return YYID ( yyresult ) ;
2006-04-24 17:41:27 +00:00
}
2008-11-02 18:52:13 +00:00
# line 701 "ael.y"
2006-04-24 17:41:27 +00:00
2006-04-26 18:43:29 +00:00
static char * token_equivs1 [ ] =
2006-04-24 17:41:27 +00:00
{
" AMPER " ,
" AT " ,
" BAR " ,
" COLON " ,
" COMMA " ,
" EQ " ,
" EXTENMARK " ,
2006-04-26 18:43:29 +00:00
" KW_BREAK " ,
" KW_CASE " ,
" KW_CATCH " ,
2006-04-24 17:41:27 +00:00
" KW_CONTEXT " ,
2006-04-26 18:43:29 +00:00
" KW_CONTINUE " ,
" KW_DEFAULT " ,
2006-04-24 17:41:27 +00:00
" KW_ELSE " ,
" KW_ESWITCHES " ,
2006-04-26 18:43:29 +00:00
" KW_FOR " ,
2006-04-24 17:41:27 +00:00
" KW_GLOBALS " ,
" KW_GOTO " ,
" KW_HINT " ,
" KW_IFTIME " ,
" KW_IF " ,
" KW_IGNOREPAT " ,
" KW_INCLUDES "
" KW_JUMP " ,
" KW_MACRO " ,
2006-04-26 18:43:29 +00:00
" KW_PATTERN " ,
" KW_REGEXTEN " ,
" KW_RETURN " ,
" KW_SWITCHES " ,
2006-04-24 17:41:27 +00:00
" KW_SWITCH " ,
2006-04-26 18:43:29 +00:00
" KW_WHILE " ,
2006-04-24 17:41:27 +00:00
" LC " ,
" LP " ,
" RC " ,
" RP " ,
" SEMI " ,
} ;
2006-04-26 18:43:29 +00:00
static char * token_equivs2 [ ] =
2006-04-24 17:41:27 +00:00
{
" & " ,
" @ " ,
" | " ,
" : " ,
" , " ,
" = " ,
" => " ,
2006-04-26 18:43:29 +00:00
" break " ,
" case " ,
" catch " ,
2006-04-24 17:41:27 +00:00
" context " ,
2006-04-26 18:43:29 +00:00
" continue " ,
" default " ,
2006-04-24 17:41:27 +00:00
" else " ,
" eswitches " ,
2006-04-26 18:43:29 +00:00
" for " ,
2006-04-24 17:41:27 +00:00
" globals " ,
" goto " ,
" hint " ,
" ifTime " ,
" if " ,
" ignorepat " ,
" includes "
" jump " ,
" macro " ,
2006-04-26 18:43:29 +00:00
" pattern " ,
" regexten " ,
" return " ,
" switches " ,
2006-04-24 17:41:27 +00:00
" switch " ,
2006-04-26 18:43:29 +00:00
" while " ,
2006-04-24 17:41:27 +00:00
" { " ,
" ( " ,
" } " ,
" ) " ,
" ; " ,
} ;
2007-09-27 00:06:06 +00:00
static char * ael_token_subst ( const char * mess )
2006-04-24 17:41:27 +00:00
{
/* calc a length, malloc, fill, and return; yyerror had better free it! */
int len = 0 , i ;
2007-09-27 00:06:06 +00:00
const char * p ;
2006-04-24 17:41:27 +00:00
char * res , * s , * t ;
int token_equivs_entries = sizeof ( token_equivs1 ) / sizeof ( char * ) ;
for ( p = mess ; * p ; p + + ) {
for ( i = 0 ; i < token_equivs_entries ; i + + ) {
if ( strncmp ( p , token_equivs1 [ i ] , strlen ( token_equivs1 [ i ] ) ) = = 0 )
{
len + = strlen ( token_equivs2 [ i ] ) + 2 ;
p + = strlen ( token_equivs1 [ i ] ) - 1 ;
break ;
}
}
len + + ;
}
2006-05-02 03:03:27 +00:00
res = calloc ( 1 , len + 1 ) ;
2006-04-24 17:41:27 +00:00
res [ 0 ] = 0 ;
s = res ;
for ( p = mess ; * p ; ) {
int found = 0 ;
for ( i = 0 ; i < token_equivs_entries ; i + + ) {
if ( strncmp ( p , token_equivs1 [ i ] , strlen ( token_equivs1 [ i ] ) ) = = 0 ) {
* s + + = ' \' ' ;
for ( t = token_equivs2 [ i ] ; * t ; ) {
* s + + = * t + + ;
}
* s + + = ' \' ' ;
p + = strlen ( token_equivs1 [ i ] ) ;
found = 1 ;
break ;
}
}
if ( ! found )
* s + + = * p + + ;
}
* s + + = 0 ;
return res ;
}
void yyerror ( YYLTYPE * locp , struct parse_io * parseio , char const * s )
{
2007-10-24 04:44:27 +00:00
char * s2 = ael_token_subst ( ( char * ) s ) ;
2006-04-24 17:41:27 +00:00
if ( locp - > first_line = = locp - > last_line ) {
ast_log ( LOG_ERROR , " ==== File: %s, Line %d, Cols: %d-%d: Error: %s \n " , my_file , locp - > first_line , locp - > first_column , locp - > last_column , s2 ) ;
} else {
ast_log ( LOG_ERROR , " ==== File: %s, Line %d Col %d to Line %d Col %d: Error: %s \n " , my_file , locp - > first_line , locp - > first_column , locp - > last_line , locp - > last_column , s2 ) ;
}
free ( s2 ) ;
parseio - > syntax_error_count + + ;
}
2007-08-15 19:21:27 +00:00
struct pval * npval ( pvaltype type , int first_line , int last_line ,
2006-04-27 17:39:55 +00:00
int first_column , int last_column )
2006-04-24 17:41:27 +00:00
{
2006-05-02 03:03:27 +00:00
pval * z = calloc ( 1 , sizeof ( struct pval ) ) ;
2006-04-24 17:41:27 +00:00
z - > type = type ;
z - > startline = first_line ;
z - > endline = last_line ;
z - > startcol = first_column ;
z - > endcol = last_column ;
z - > filename = strdup ( my_file ) ;
return z ;
}
2006-04-27 18:09:20 +00:00
static struct pval * npval2 ( pvaltype type , YYLTYPE * first , YYLTYPE * last )
{
return npval ( type , first - > first_line , last - > last_line ,
first - > first_column , last - > last_column ) ;
}
2006-04-30 12:12:39 +00:00
static struct pval * update_last ( pval * obj , YYLTYPE * last )
{
obj - > endline = last - > last_line ;
obj - > endcol = last - > last_column ;
return obj ;
}
2006-04-30 13:57:08 +00:00
/* frontend for npval to create a PV_WORD string from the given token */
static pval * nword ( char * string , YYLTYPE * pos )
{
pval * p = npval2 ( PV_WORD , pos , pos ) ;
if ( p )
p - > u1 . str = string ;
return p ;
}
2006-08-07 12:59:47 +00:00
/* this routine adds a dad ptr to each element in the list */
static void set_dads ( struct pval * dad , struct pval * child_list )
{
struct pval * t ;
for ( t = child_list ; t ; t = t - > next ) /* simple stuff */
t - > dad = dad ;
}