asterisk/res/ael/ael_lex.c

3496 lines
101 KiB
C
Raw Normal View History

#define ASTMM_LIBC ASTMM_REDIRECT
#include "asterisk.h"
#line 2 "ael_lex.c"
#line 4 "ael_lex.c"
#define YY_INT_ALIGNED short int
/* A lexical scanner generated by flex */
#define FLEX_SCANNER
#define YY_FLEX_MAJOR_VERSION 2
#define YY_FLEX_MINOR_VERSION 5
#define YY_FLEX_SUBMINOR_VERSION 35
#if YY_FLEX_SUBMINOR_VERSION > 0
#define FLEX_BETA
#endif
/* First, we deal with platform-specific or compiler-specific issues. */
/* begin standard C headers. */
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <stdlib.h>
/* end standard C headers. */
/* flex integer type definitions */
#ifndef FLEXINT_H
#define FLEXINT_H
/* C99 systems have <inttypes.h>. Non-C99 systems may or may not. */
#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
/* C99 says to define __STDC_LIMIT_MACROS before including stdint.h,
* if you want the limit (max/min) macros for int types.
*/
#ifndef __STDC_LIMIT_MACROS
#define __STDC_LIMIT_MACROS 1
#endif
#include <inttypes.h>
typedef int8_t flex_int8_t;
typedef uint8_t flex_uint8_t;
typedef int16_t flex_int16_t;
typedef uint16_t flex_uint16_t;
typedef int32_t flex_int32_t;
typedef uint32_t flex_uint32_t;
#else
typedef signed char flex_int8_t;
typedef short int flex_int16_t;
typedef int flex_int32_t;
typedef unsigned char flex_uint8_t;
typedef unsigned short int flex_uint16_t;
typedef unsigned int flex_uint32_t;
/* Limits of integral types. */
#ifndef INT8_MIN
#define INT8_MIN (-128)
#endif
#ifndef INT16_MIN
#define INT16_MIN (-32767-1)
#endif
#ifndef INT32_MIN
#define INT32_MIN (-2147483647-1)
#endif
#ifndef INT8_MAX
#define INT8_MAX (127)
#endif
#ifndef INT16_MAX
#define INT16_MAX (32767)
#endif
#ifndef INT32_MAX
#define INT32_MAX (2147483647)
#endif
#ifndef UINT8_MAX
#define UINT8_MAX (255U)
#endif
#ifndef UINT16_MAX
#define UINT16_MAX (65535U)
#endif
#ifndef UINT32_MAX
#define UINT32_MAX (4294967295U)
#endif
#endif /* ! C99 */
#endif /* ! FLEXINT_H */
#ifdef __cplusplus
/* The "const" storage-class-modifier is valid. */
#define YY_USE_CONST
#else /* ! __cplusplus */
/* C99 requires __STDC__ to be defined as 1. */
#if defined (__STDC__)
#define YY_USE_CONST
#endif /* defined (__STDC__) */
#endif /* ! __cplusplus */
#ifdef YY_USE_CONST
#define yyconst const
#else
#define yyconst
#endif
/* Returned upon end-of-file. */
#define YY_NULL 0
/* Promotes a possibly negative, possibly signed char to an unsigned
* integer for use as an array index. If the signed char is negative,
* we want to instead treat it as an 8-bit unsigned char, hence the
* double cast.
*/
#define YY_SC_TO_UI(c) ((unsigned int) (unsigned char) c)
/* An opaque pointer. */
#ifndef YY_TYPEDEF_YY_SCANNER_T
#define YY_TYPEDEF_YY_SCANNER_T
typedef void* yyscan_t;
#endif
/* For convenience, these vars (plus the bison vars far below)
are macros in the reentrant scanner. */
#define yyin yyg->yyin_r
#define yyout yyg->yyout_r
#define yyextra yyg->yyextra_r
#define yyleng yyg->yyleng_r
#define yytext yyg->yytext_r
#define yylineno (YY_CURRENT_BUFFER_LVALUE->yy_bs_lineno)
#define yycolumn (YY_CURRENT_BUFFER_LVALUE->yy_bs_column)
#define yy_flex_debug yyg->yy_flex_debug_r
/* Enter a start condition. This macro really ought to take a parameter,
* but we do it the disgusting crufty way forced on us by the ()-less
* definition of BEGIN.
*/
#define BEGIN yyg->yy_start = 1 + 2 *
/* Translate the current start state into a value that can be later handed
* to BEGIN to return to the state. The YYSTATE alias is for lex
* compatibility.
*/
#define YY_START ((yyg->yy_start - 1) / 2)
#define YYSTATE YY_START
/* Action number for EOF rule of a given start state. */
#define YY_STATE_EOF(state) (YY_END_OF_BUFFER + state + 1)
/* Special action meaning "start processing a new file". */
#define YY_NEW_FILE ael_yyrestart(yyin ,yyscanner )
#define YY_END_OF_BUFFER_CHAR 0
/* Size of default input buffer. */
#ifndef YY_BUF_SIZE
#ifdef __ia64__
/* On IA-64, the buffer size is 16k, not 8k.
* Moreover, YY_BUF_SIZE is 2*YY_READ_BUF_SIZE in the general case.
* Ditto for the __ia64__ case accordingly.
*/
#define YY_BUF_SIZE 32768
#else
#define YY_BUF_SIZE 16384
#endif /* __ia64__ */
#endif
/* The state buf must be large enough to hold one state per character in the main buffer.
*/
#define YY_STATE_BUF_SIZE ((YY_BUF_SIZE + 2) * sizeof(yy_state_type))
#ifndef YY_TYPEDEF_YY_BUFFER_STATE
#define YY_TYPEDEF_YY_BUFFER_STATE
typedef struct yy_buffer_state *YY_BUFFER_STATE;
#endif
#define EOB_ACT_CONTINUE_SCAN 0
#define EOB_ACT_END_OF_FILE 1
#define EOB_ACT_LAST_MATCH 2
#define YY_LESS_LINENO(n)
/* Return all but the first "n" matched characters back to the input stream. */
#define yyless(n) \
do \
{ \
/* Undo effects of setting up yytext. */ \
int yyless_macro_arg = (n); \
YY_LESS_LINENO(yyless_macro_arg);\
*yy_cp = yyg->yy_hold_char; \
YY_RESTORE_YY_MORE_OFFSET \
yyg->yy_c_buf_p = yy_cp = yy_bp + yyless_macro_arg - YY_MORE_ADJ; \
YY_DO_BEFORE_ACTION; /* set up yytext again */ \
} \
while ( 0 )
#define unput(c) yyunput( c, yyg->yytext_ptr , yyscanner )
#ifndef YY_TYPEDEF_YY_SIZE_T
#define YY_TYPEDEF_YY_SIZE_T
typedef size_t yy_size_t;
#endif
#ifndef YY_STRUCT_YY_BUFFER_STATE
#define YY_STRUCT_YY_BUFFER_STATE
struct yy_buffer_state
{
FILE *yy_input_file;
char *yy_ch_buf; /* input buffer */
char *yy_buf_pos; /* current position in input buffer */
/* Size of input buffer in bytes, not including room for EOB
* characters.
*/
yy_size_t yy_buf_size;
/* Number of characters read into yy_ch_buf, not including EOB
* characters.
*/
int yy_n_chars;
/* Whether we "own" the buffer - i.e., we know we created it,
* and can realloc() it to grow it, and should free() it to
* delete it.
*/
int yy_is_our_buffer;
/* Whether this is an "interactive" input source; if so, and
* if we're using stdio for input, then we want to use getc()
* instead of fread(), to make sure we stop fetching input after
* each newline.
*/
int yy_is_interactive;
/* Whether we're considered to be at the beginning of a line.
* If so, '^' rules will be active on the next match, otherwise
* not.
*/
int yy_at_bol;
int yy_bs_lineno; /**< The line count. */
int yy_bs_column; /**< The column count. */
/* Whether to try to fill the input buffer when we reach the
* end of it.
*/
int yy_fill_buffer;
int yy_buffer_status;
#define YY_BUFFER_NEW 0
#define YY_BUFFER_NORMAL 1
/* When an EOF's been seen but there's still some text to process
* then we mark the buffer as YY_EOF_PENDING, to indicate that we
* shouldn't try reading from the input source any more. We might
* still have a bunch of tokens to match, though, because of
* possible backing-up.
*
* When we actually see the EOF, we change the status to "new"
* (via ael_yyrestart()), so that the user can continue scanning by
* just pointing yyin at a new input file.
*/
#define YY_BUFFER_EOF_PENDING 2
};
#endif /* !YY_STRUCT_YY_BUFFER_STATE */
/* We provide macros for accessing buffer states in case in the
* future we want to put the buffer states in a more general
* "scanner state".
*
* Returns the top of the stack, or NULL.
*/
#define YY_CURRENT_BUFFER ( yyg->yy_buffer_stack \
? yyg->yy_buffer_stack[yyg->yy_buffer_stack_top] \
: NULL)
/* Same as previous macro, but useful when we know that the buffer stack is not
* NULL or when we need an lvalue. For internal use only.
*/
#define YY_CURRENT_BUFFER_LVALUE yyg->yy_buffer_stack[yyg->yy_buffer_stack_top]
void ael_yyrestart (FILE *input_file ,yyscan_t yyscanner );
void ael_yy_switch_to_buffer (YY_BUFFER_STATE new_buffer ,yyscan_t yyscanner );
YY_BUFFER_STATE ael_yy_create_buffer (FILE *file,int size ,yyscan_t yyscanner );
void ael_yy_delete_buffer (YY_BUFFER_STATE b ,yyscan_t yyscanner );
void ael_yy_flush_buffer (YY_BUFFER_STATE b ,yyscan_t yyscanner );
void ael_yypush_buffer_state (YY_BUFFER_STATE new_buffer ,yyscan_t yyscanner );
void ael_yypop_buffer_state (yyscan_t yyscanner );
static void ael_yyensure_buffer_stack (yyscan_t yyscanner );
static void ael_yy_load_buffer_state (yyscan_t yyscanner );
static void ael_yy_init_buffer (YY_BUFFER_STATE b,FILE *file ,yyscan_t yyscanner );
#define YY_FLUSH_BUFFER ael_yy_flush_buffer(YY_CURRENT_BUFFER ,yyscanner)
YY_BUFFER_STATE ael_yy_scan_buffer (char *base,yy_size_t size ,yyscan_t yyscanner );
YY_BUFFER_STATE ael_yy_scan_string (yyconst char *yy_str ,yyscan_t yyscanner );
YY_BUFFER_STATE ael_yy_scan_bytes (yyconst char *bytes,int len ,yyscan_t yyscanner );
void *ael_yyalloc (yy_size_t ,yyscan_t yyscanner );
void *ael_yyrealloc (void *,yy_size_t ,yyscan_t yyscanner );
void ael_yyfree (void * ,yyscan_t yyscanner );
#define yy_new_buffer ael_yy_create_buffer
#define yy_set_interactive(is_interactive) \
{ \
if ( ! YY_CURRENT_BUFFER ){ \
ael_yyensure_buffer_stack (yyscanner); \
YY_CURRENT_BUFFER_LVALUE = \
ael_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner); \
} \
YY_CURRENT_BUFFER_LVALUE->yy_is_interactive = is_interactive; \
}
#define yy_set_bol(at_bol) \
{ \
if ( ! YY_CURRENT_BUFFER ){\
ael_yyensure_buffer_stack (yyscanner); \
YY_CURRENT_BUFFER_LVALUE = \
ael_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner); \
} \
YY_CURRENT_BUFFER_LVALUE->yy_at_bol = at_bol; \
}
#define YY_AT_BOL() (YY_CURRENT_BUFFER_LVALUE->yy_at_bol)
/* Begin user sect3 */
#define ael_yywrap(n) 1
#define YY_SKIP_YYWRAP
typedef unsigned char YY_CHAR;
typedef int yy_state_type;
#define yytext_ptr yytext_r
static yy_state_type yy_get_previous_state (yyscan_t yyscanner );
static yy_state_type yy_try_NUL_trans (yy_state_type current_state ,yyscan_t yyscanner);
static int yy_get_next_buffer (yyscan_t yyscanner );
static void yy_fatal_error (yyconst char msg[] ,yyscan_t yyscanner );
/* Done after the current pattern has been matched and before the
* corresponding action - sets up yytext.
*/
#define YY_DO_BEFORE_ACTION \
yyg->yytext_ptr = yy_bp; \
yyg->yytext_ptr -= yyg->yy_more_len; \
yyleng = (size_t) (yy_cp - yyg->yytext_ptr); \
yyg->yy_hold_char = *yy_cp; \
*yy_cp = '\0'; \
yyg->yy_c_buf_p = yy_cp;
#define YY_NUM_RULES 76
#define YY_END_OF_BUFFER 77
/* This struct is not used in this scanner,
but its presence is necessary. */
struct yy_trans_info
{
flex_int32_t yy_verify;
flex_int32_t yy_nxt;
};
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
static yyconst flex_int16_t yy_accept[285] =
{ 0,
0, 0, 0, 0, 0, 0, 0, 0, 43, 43,
0, 0, 0, 0, 0, 0, 77, 75, 50, 48,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
49, 51, 51, 51, 9, 3, 4, 7, 51, 8,
5, 6, 12, 75, 51, 51, 51, 51, 51, 51,
51, 51, 51, 51, 51, 51, 51, 51, 51, 51,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
1, 10, 2, 75, 65, 64, 75, 66, 75, 71,
72, 73, 75, 75, 67, 68, 69, 75, 70, 43,
44, 45, 75, 59, 60, 75, 58, 57, 52, 52,
57, 53, 75, 62, 63, 75, 61, 50, 49, 0,
51, 42, 13, 11, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 22, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 65, 64,
0, 66, 65, 64, 66, 0, 71, 72, 73, 0,
71, 72, 73, 0, 67, 68, 69, 0, 70, 67,
68, 69, 70, 43, 44, 45, 46, 45, 47, 0,
59, 60, 0, 58, 59, 60, 58, 56, 55, 54,
0, 62, 63, 0, 61, 62, 63, 61, 0, 13,
0, 0, 0, 0, 0, 0, 0, 0, 0, 33,
0, 0, 0, 51, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 35, 0,
0, 0, 27, 0, 0, 0, 28, 26, 0, 0,
0, 29, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 31, 38, 0, 0, 0, 0, 0, 0,
0, 0, 0, 19, 17, 0, 0, 0, 0, 0,
34, 0, 0, 0, 0, 0, 0, 16, 0, 23,
0, 0, 0, 24, 0, 30, 21, 0, 0, 14,
0, 36, 0, 18, 0, 0, 37, 0, 51, 0,
15, 32, 0, 0, 41, 25, 39, 0, 40, 20,
0, 0, 74, 0
} ;
static yyconst flex_int32_t yy_ec[256] =
{ 0,
1, 1, 1, 1, 1, 1, 1, 1, 2, 3,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
1, 4, 5, 6, 7, 8, 1, 9, 5, 10,
11, 12, 5, 13, 5, 5, 14, 5, 5, 5,
5, 5, 5, 5, 5, 5, 5, 15, 16, 5,
17, 18, 1, 19, 5, 5, 5, 5, 5, 5,
5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
5, 5, 5, 20, 5, 5, 5, 5, 5, 5,
21, 22, 23, 1, 5, 1, 24, 25, 26, 27,
28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39, 5, 40, 41, 42, 43, 5, 44, 45,
5, 5, 46, 47, 48, 1, 1, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49, 49, 49, 49, 49, 49,
49, 49, 49, 49, 49
} ;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
static yyconst flex_int32_t yy_meta[50] =
{ 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
1, 1, 2, 1, 3, 4, 3, 3, 1, 1,
1, 5, 1, 3, 1, 1, 1, 3, 1, 3,
3, 1, 3, 3, 3, 3, 3, 3, 3, 3,
3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
3, 3, 3, 3, 3, 1, 1, 1, 1
} ;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
static yyconst flex_int16_t yy_base[304] =
{ 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 40, 43, 82, 121, 160, 199, 55, 56,
60, 74, 247, 296, 90, 104, 432, 1023, 429, 1023,
426, 1023, 397, 31, 1023, 1023, 1023, 1023, 43, 1023,
1023, 410, 1023, 0, 401, 382, 36, 389, 34, 378,
38, 380, 80, 368, 372, 385, 381, 66, 357, 369,
1023, 1023, 1023, 138, 1023, 1023, 143, 1023, 336, 1023,
1023, 1023, 375, 414, 1023, 1023, 1023, 453, 1023, 396,
1023, 104, 177, 1023, 1023, 182, 1023, 1023, 1023, 78,
0, 1023, 231, 1023, 1023, 262, 1023, 393, 390, 356,
1023, 1023, 0, 1023, 348, 360, 92, 350, 354, 337,
333, 333, 333, 334, 329, 333, 344, 326, 335, 320,
327, 322, 299, 303, 93, 302, 301, 280, 1023, 1023,
314, 1023, 328, 344, 358, 492, 1023, 1023, 1023, 531,
570, 609, 648, 687, 1023, 1023, 1023, 726, 1023, 765,
804, 843, 882, 329, 1023, 143, 1023, 144, 1023, 392,
1023, 1023, 397, 1023, 431, 436, 470, 1023, 1023, 1023,
475, 1023, 1023, 484, 1023, 514, 523, 553, 305, 0,
288, 305, 299, 297, 280, 297, 292, 287, 289, 0,
291, 276, 250, 257, 250, 252, 247, 258, 241, 238,
251, 248, 232, 232, 236, 235, 228, 233, 0, 234,
113, 218, 0, 217, 209, 220, 0, 0, 207, 200,
196, 0, 203, 199, 208, 197, 189, 193, 206, 203,
186, 203, 0, 0, 181, 187, 184, 192, 190, 181,
187, 186, 186, 0, 0, 171, 171, 160, 164, 166,
0, 169, 169, 152, 147, 143, 149, 0, 138, 0,
139, 149, 138, 0, 140, 0, 135, 134, 109, 0,
112, 0, 111, 0, 105, 80, 0, 82, 61, 76,
0, 0, 46, 30, 0, 0, 0, 170, 0, 0,
0, 50, 1023, 1023, 930, 935, 940, 945, 950, 955,
960, 965, 970, 975, 980, 985, 989, 994, 999, 1004,
1009, 1012, 1017
} ;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
static yyconst flex_int16_t yy_def[304] =
{ 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
284, 1, 285, 285, 286, 286, 287, 287, 288, 288,
289, 289, 290, 290, 291, 291, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 292, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 293, 284, 284, 293, 284, 294, 284,
284, 284, 294, 295, 284, 284, 284, 295, 284, 296,
284, 297, 298, 284, 284, 298, 284, 284, 284, 284,
299, 284, 300, 284, 284, 300, 284, 284, 284, 284,
284, 284, 301, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 302, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 293, 284, 284,
293, 284, 293, 293, 293, 294, 284, 284, 284, 294,
294, 294, 294, 295, 284, 284, 284, 295, 284, 295,
295, 295, 295, 296, 284, 297, 284, 297, 284, 298,
284, 284, 298, 284, 298, 298, 298, 284, 284, 284,
300, 284, 284, 300, 284, 300, 300, 300, 284, 301,
284, 284, 284, 284, 284, 284, 284, 284, 284, 302,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 302, 284,
284, 284, 302, 284, 284, 284, 302, 302, 284, 284,
284, 302, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 302, 302, 284, 284, 284, 284, 284, 284,
284, 284, 284, 302, 302, 284, 284, 284, 284, 284,
302, 284, 284, 284, 284, 284, 284, 302, 284, 302,
284, 284, 284, 302, 284, 302, 302, 284, 284, 302,
284, 302, 284, 302, 284, 284, 302, 284, 284, 284,
302, 302, 284, 284, 302, 302, 302, 284, 302, 302,
303, 303, 284, 0, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284
} ;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
static yyconst flex_int16_t yy_nxt[1073] =
{ 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
18, 19, 20, 21, 22, 22, 23, 24, 25, 26,
27, 22, 28, 29, 30, 31, 32, 22, 33, 22,
22, 34, 22, 35, 36, 37, 38, 39, 40, 41,
42, 43, 44, 22, 45, 46, 22, 22, 47, 48,
49, 22, 22, 50, 22, 51, 52, 53, 22, 55,
56, 91, 55, 56, 92, 283, 93, 71, 71, 97,
55, 57, 58, 55, 57, 58, 72, 72, 100, 74,
75, 280, 104, 98, 101, 105, 91, 278, 102, 278,
74, 76, 75, 74, 75, 55, 279, 58, 55, 114,
58, 60, 61, 115, 74, 76, 75, 62, 158, 84,
85, 277, 60, 63, 61, 74, 147, 77, 107, 108,
84, 86, 87, 84, 85, 148, 109, 149, 276, 74,
275, 77, 192, 159, 84, 86, 87, 60, 274, 61,
60, 61, 173, 174, 193, 84, 62, 85, 273, 272,
225, 60, 63, 61, 226, 147, 147, 119, 120, 84,
271, 85, 123, 124, 284, 148, 284, 284, 119, 121,
122, 270, 269, 123, 121, 125, 60, 268, 61, 65,
66, 278, 67, 278, 267, 281, 266, 265, 264, 263,
65, 68, 69, 119, 262, 122, 151, 152, 123, 261,
125, 155, 156, 260, 259, 258, 257, 151, 153, 152,
256, 255, 155, 153, 156, 65, 254, 69, 65, 66,
253, 67, 252, 251, 250, 249, 248, 247, 246, 65,
68, 69, 151, 245, 154, 244, 243, 155, 242, 157,
241, 240, 239, 238, 237, 236, 235, 234, 233, 232,
162, 163, 231, 230, 65, 229, 69, 78, 78, 78,
78, 162, 164, 165, 80, 78, 78, 78, 228, 78,
227, 78, 78, 78, 224, 78, 223, 222, 81, 221,
220, 166, 167, 219, 218, 217, 162, 216, 163, 215,
214, 213, 166, 164, 168, 212, 211, 210, 209, 119,
120, 208, 78, 78, 78, 82, 78, 78, 78, 78,
119, 121, 122, 80, 78, 78, 78, 166, 78, 167,
78, 78, 78, 207, 78, 206, 205, 81, 204, 203,
202, 201, 200, 123, 124, 119, 199, 122, 198, 197,
196, 145, 195, 194, 123, 121, 125, 119, 120, 191,
190, 78, 78, 78, 82, 127, 128, 189, 119, 121,
122, 129, 188, 119, 120, 187, 127, 130, 128, 123,
186, 125, 185, 184, 119, 121, 122, 119, 120, 183,
182, 181, 180, 119, 179, 122, 178, 177, 119, 121,
122, 127, 176, 128, 131, 132, 175, 172, 171, 119,
133, 122, 169, 89, 88, 131, 130, 132, 145, 117,
116, 151, 152, 119, 113, 122, 155, 156, 112, 111,
110, 106, 151, 153, 152, 103, 99, 155, 153, 156,
131, 96, 132, 135, 136, 95, 137, 94, 90, 89,
88, 284, 284, 284, 135, 138, 139, 151, 284, 154,
151, 152, 155, 284, 157, 151, 152, 284, 284, 284,
284, 151, 153, 152, 284, 284, 151, 153, 152, 135,
284, 139, 140, 141, 284, 142, 284, 284, 284, 284,
284, 284, 284, 140, 138, 143, 151, 284, 154, 151,
152, 151, 284, 154, 162, 163, 284, 284, 284, 284,
151, 153, 152, 166, 167, 162, 164, 165, 140, 284,
143, 127, 128, 284, 166, 164, 168, 129, 284, 284,
284, 284, 127, 130, 128, 151, 284, 154, 284, 284,
162, 284, 163, 162, 163, 284, 284, 284, 284, 166,
284, 167, 162, 163, 162, 164, 165, 127, 284, 128,
131, 132, 284, 162, 164, 165, 133, 284, 284, 284,
284, 131, 130, 132, 284, 284, 284, 284, 284, 162,
284, 163, 162, 163, 284, 284, 284, 284, 162, 284,
163, 284, 284, 162, 164, 165, 131, 284, 132, 127,
128, 284, 284, 284, 284, 129, 284, 284, 284, 284,
127, 130, 128, 284, 284, 284, 284, 284, 162, 284,
163, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 127, 284, 128, 127, 128,
284, 284, 284, 284, 129, 284, 284, 284, 284, 127,
130, 128, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 127, 284, 128, 127, 128, 284,
284, 284, 284, 129, 284, 284, 284, 284, 127, 130,
128, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 127, 284, 128, 135, 136, 284, 137,
284, 284, 284, 284, 284, 284, 284, 135, 138, 139,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 135, 284, 139, 140, 141, 284, 142, 284,
284, 284, 284, 284, 284, 284, 140, 138, 143, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 140, 284, 143, 135, 136, 284, 137, 284, 284,
284, 284, 284, 284, 284, 135, 138, 139, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
135, 284, 139, 135, 136, 284, 137, 284, 284, 284,
284, 284, 284, 284, 135, 138, 139, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 135,
284, 139, 135, 136, 284, 137, 284, 284, 284, 284,
284, 284, 284, 135, 138, 139, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 135, 284,
139, 135, 136, 284, 137, 284, 284, 284, 284, 284,
284, 284, 135, 138, 139, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 135, 284, 139,
54, 54, 54, 54, 54, 59, 59, 59, 59, 59,
64, 64, 64, 64, 64, 70, 70, 70, 70, 70,
73, 73, 73, 73, 73, 79, 79, 79, 79, 79,
83, 83, 83, 83, 83, 91, 284, 91, 91, 91,
118, 118, 118, 118, 118, 126, 126, 126, 126, 126,
134, 134, 134, 134, 134, 144, 144, 144, 144, 146,
146, 146, 146, 146, 150, 150, 150, 150, 150, 160,
284, 160, 160, 160, 161, 161, 161, 161, 161, 170,
284, 170, 170, 170, 91, 91, 91, 282, 282, 282,
284, 282, 17, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284
} ;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
static yyconst flex_int16_t yy_chk[1073] =
{ 0,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
1, 1, 1, 1, 1, 1, 1, 1, 1, 3,
3, 24, 4, 4, 29, 282, 29, 9, 10, 37,
3, 3, 3, 4, 4, 4, 9, 10, 39, 11,
11, 274, 41, 37, 39, 41, 24, 270, 39, 270,
11, 11, 11, 12, 12, 3, 273, 3, 4, 48,
4, 5, 5, 48, 12, 12, 12, 5, 80, 15,
15, 269, 5, 5, 5, 11, 72, 11, 43, 43,
15, 15, 15, 16, 16, 72, 43, 72, 268, 12,
266, 12, 115, 80, 16, 16, 16, 5, 265, 5,
6, 6, 97, 97, 115, 15, 6, 15, 263, 261,
201, 6, 6, 6, 201, 146, 148, 54, 54, 16,
259, 16, 57, 57, 146, 148, 146, 148, 54, 54,
54, 258, 257, 57, 57, 57, 6, 255, 6, 7,
7, 278, 7, 278, 253, 278, 252, 251, 249, 247,
7, 7, 7, 54, 246, 54, 73, 73, 57, 245,
57, 76, 76, 244, 243, 242, 240, 73, 73, 73,
239, 238, 76, 76, 76, 7, 237, 7, 8, 8,
236, 8, 233, 232, 231, 230, 229, 228, 227, 8,
8, 8, 73, 226, 73, 225, 222, 76, 221, 76,
220, 219, 218, 217, 216, 215, 214, 213, 211, 210,
83, 83, 209, 206, 8, 205, 8, 13, 13, 13,
13, 83, 83, 83, 13, 13, 13, 13, 204, 13,
202, 13, 13, 13, 200, 13, 198, 197, 13, 196,
195, 86, 86, 194, 193, 192, 83, 191, 83, 190,
189, 188, 86, 86, 86, 187, 186, 185, 184, 118,
118, 183, 13, 13, 13, 13, 14, 14, 14, 14,
118, 118, 118, 14, 14, 14, 14, 86, 14, 86,
14, 14, 14, 182, 14, 181, 179, 14, 178, 177,
176, 175, 174, 121, 121, 118, 173, 118, 172, 171,
169, 144, 117, 116, 121, 121, 121, 123, 123, 114,
113, 14, 14, 14, 14, 59, 59, 112, 123, 123,
123, 59, 111, 124, 124, 110, 59, 59, 59, 121,
109, 121, 108, 107, 124, 124, 124, 125, 125, 106,
105, 104, 103, 123, 102, 123, 101, 100, 125, 125,
125, 59, 99, 59, 63, 63, 98, 96, 95, 124,
63, 124, 90, 89, 88, 63, 63, 63, 70, 50,
49, 150, 150, 125, 47, 125, 153, 153, 46, 45,
44, 42, 150, 150, 150, 40, 38, 153, 153, 153,
63, 36, 63, 64, 64, 35, 64, 32, 23, 21,
19, 17, 0, 0, 64, 64, 64, 150, 0, 150,
155, 155, 153, 0, 153, 156, 156, 0, 0, 0,
0, 155, 155, 155, 0, 0, 156, 156, 156, 64,
0, 64, 68, 68, 0, 68, 0, 0, 0, 0,
0, 0, 0, 68, 68, 68, 155, 0, 155, 157,
157, 156, 0, 156, 161, 161, 0, 0, 0, 0,
157, 157, 157, 164, 164, 161, 161, 161, 68, 0,
68, 126, 126, 0, 164, 164, 164, 126, 0, 0,
0, 0, 126, 126, 126, 157, 0, 157, 0, 0,
161, 0, 161, 166, 166, 0, 0, 0, 0, 164,
0, 164, 167, 167, 166, 166, 166, 126, 0, 126,
130, 130, 0, 167, 167, 167, 130, 0, 0, 0,
0, 130, 130, 130, 0, 0, 0, 0, 0, 166,
0, 166, 168, 168, 0, 0, 0, 0, 167, 0,
167, 0, 0, 168, 168, 168, 130, 0, 130, 131,
131, 0, 0, 0, 0, 131, 0, 0, 0, 0,
131, 131, 131, 0, 0, 0, 0, 0, 168, 0,
168, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 131, 0, 131, 132, 132,
0, 0, 0, 0, 132, 0, 0, 0, 0, 132,
132, 132, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 0, 0, 132, 0, 132, 133, 133, 0,
0, 0, 0, 133, 0, 0, 0, 0, 133, 133,
133, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 0, 133, 0, 133, 134, 134, 0, 134,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 0, 0, 0, 0, 0, 134, 134, 134,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 134, 0, 134, 138, 138, 0, 138, 0,
0, 0, 0, 0, 0, 0, 138, 138, 138, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 138, 0, 138, 140, 140, 0, 140, 0, 0,
0, 0, 0, 0, 0, 140, 140, 140, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
140, 0, 140, 141, 141, 0, 141, 0, 0, 0,
0, 0, 0, 0, 141, 141, 141, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 0, 0, 0, 0, 0, 0, 0, 141,
0, 141, 142, 142, 0, 142, 0, 0, 0, 0,
0, 0, 0, 142, 142, 142, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 0, 0, 0, 0, 0, 0, 142, 0,
142, 143, 143, 0, 143, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 143, 143, 143, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
0, 0, 0, 0, 0, 0, 0, 143, 0, 143,
285, 285, 285, 285, 285, 286, 286, 286, 286, 286,
287, 287, 287, 287, 287, 288, 288, 288, 288, 288,
289, 289, 289, 289, 289, 290, 290, 290, 290, 290,
291, 291, 291, 291, 291, 292, 0, 292, 292, 292,
293, 293, 293, 293, 293, 294, 294, 294, 294, 294,
295, 295, 295, 295, 295, 296, 296, 296, 296, 297,
297, 297, 297, 297, 298, 298, 298, 298, 298, 299,
0, 299, 299, 299, 300, 300, 300, 300, 300, 301,
0, 301, 301, 301, 302, 302, 302, 303, 303, 303,
0, 303, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284, 284, 284, 284, 284, 284, 284, 284, 284,
284, 284
} ;
/* The intent behind this definition is that it'll catch
* any uses of REJECT which flex missed.
*/
#define REJECT reject_used_but_not_detected
#define yymore() (yyg->yy_more_flag = 1)
#define YY_MORE_ADJ yyg->yy_more_len
#define YY_RESTORE_YY_MORE_OFFSET
#line 1 "ael.flex"
/*
* Asterisk -- An open source telephony toolkit.
*
* 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 Flex scanner description of tokens used in AEL2 .
*
*/
/*
* Start with flex options:
*
* %x describes the contexts we have: paren, semic and argg, plus INITIAL
*/
/* prefix used for various globally-visible functions and variables.
* This renames also ael_yywrap, but since we do not use it, we just
* add option noyywrap to remove it.
*/
/* I specify this option to suppress flex generating code with ECHO
in it. This generates compiler warnings in some systems; We've
seen the fwrite generate Unused variable warnings with 4.1.2 gcc.
Some systems have tweaked flex ECHO macro to keep the compiler
happy. To keep the warning message from getting output, I added
a default rule at the end of the patterns section */
/* ael_yyfree normally just frees its arg. It can be null sometimes,
which some systems will complain about, so, we'll define our own version */
/* batch gives a bit more performance if we are using it in
* a non-interactive mode. We probably don't care much.
*/
/* outfile is the filename to be used instead of lex.yy.c */
/*
* These are not supported in flex 2.5.4, but we need them
* at the moment:
* reentrant produces a thread-safe parser. Not 100% sure that
* we require it, though.
* bison-bridge passes an additional yylval argument to ael_yylex().
* bison-locations is probably not needed.
*/
#line 71 "ael.flex"
#include "asterisk.h"
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <glob.h>
#if !defined(GLOB_ABORTED)
#define GLOB_ABORTED GLOB_ABEND
#endif
#if !defined(GLOB_BRACE)
#define GLOB_BRACE 0
#endif
#if !defined(GLOB_NOMAGIC)
#define GLOB_NOMAGIC 0
#endif
#include "asterisk/logger.h"
#include "asterisk/utils.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"
#include "ael/ael.tab.h"
#include "asterisk/ael_structs.h"
/*
* A stack to keep track of matching brackets ( [ { } ] )
*/
static char pbcstack[400]; /* XXX missing size checks */
static int pbcpos = 0;
static void pbcpush(char x);
static int pbcpop(char x);
static int parencount = 0;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
/*
* A similar stack to keep track of matching brackets ( [ { } ] ) in word tokens surrounded by ${ ... }
*/
static char pbcstack2[400]; /* XXX missing size checks */
static int pbcpos2 = 0;
static void pbcpush2(char x);
static int pbcpop2(char x);
static int parencount2 = 0;
/*
* A similar stack to keep track of matching brackets ( [ { } ] ) in word tokens surrounded by $[ ... ]
*/
static char pbcstack3[400]; /* XXX missing size checks */
static int pbcpos3 = 0;
static void pbcpush3(char x);
static int pbcpop3(char x);
static int parencount3 = 0;
/*
* current line, column and filename, updated as we read the input.
*/
static int my_lineno = 1; /* current line in the source */
static int my_col = 1; /* current column in the source */
char *my_file = 0; /* used also in the bison code */
char *prev_word; /* XXX document it */
#define MAX_INCLUDE_DEPTH 50
/*
* flex is not too smart, and generates global functions
* without prototypes so the compiler may complain.
* To avoid that, we declare the prototypes here,
* even though these functions are not used.
*/
int ael_yyget_column (yyscan_t yyscanner);
void ael_yyset_column (int column_no , yyscan_t yyscanner);
int ael_yyparse (struct parse_io *);
/*
* A stack to process include files.
* As we switch into the new file we need to store the previous
* state to restore it later.
*/
struct stackelement {
char *fname;
int lineno;
int colno;
glob_t globbuf; /* the current globbuf */
int globbuf_pos; /* where we are in the current globbuf */
YY_BUFFER_STATE bufstate;
};
static struct stackelement include_stack[MAX_INCLUDE_DEPTH];
static int include_stack_index = 0;
static void setup_filestack(char *fnamebuf, int fnamebuf_siz, glob_t *globbuf, int globpos, yyscan_t xscan, int create);
/*
* if we use the @n feature of bison, we must supply the start/end
* location of tokens in the structure pointed by yylloc.
* Simple tokens are just assumed to be on the same line, so
* the line number is constant, and the column is incremented
* by the length of the token.
*/
#ifdef FLEX_BETA /* set for 2.5.33 */
/* compute the total number of lines and columns in the text
* passed as argument.
*/
static void pbcwhere(const char *text, int *line, int *col )
{
int loc_line = *line;
int loc_col = *col;
char c;
while ( (c = *text++) ) {
if ( c == '\t' ) {
loc_col += 8 - (loc_col % 8);
} else if ( c == '\n' ) {
loc_line++;
loc_col = 1;
} else
loc_col++;
}
*line = loc_line;
*col = loc_col;
}
#define STORE_POS do { \
yylloc->first_line = yylloc->last_line = my_lineno; \
yylloc->first_column=my_col; \
yylloc->last_column=my_col+yyleng-1; \
my_col+=yyleng; \
} while (0)
#define STORE_LOC do { \
yylloc->first_line = my_lineno; \
yylloc->first_column=my_col; \
pbcwhere(yytext, &my_lineno, &my_col); \
yylloc->last_line = my_lineno; \
yylloc->last_column = my_col - 1; \
} while (0)
#else
#define STORE_POS
#define STORE_LOC
#endif
#line 963 "ael_lex.c"
#define INITIAL 0
#define paren 1
#define semic 2
#define argg 3
#define comment 4
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
#define curlystate 5
#define wordstate 6
#define brackstate 7
#ifndef YY_NO_UNISTD_H
/* Special case for "unistd.h", since it is non-ANSI. We include it way
* down here because we want the user's section 1 to have been scanned first.
* The user has a chance to override it with an option.
*/
#include <unistd.h>
#endif
#ifndef YY_EXTRA_TYPE
#define YY_EXTRA_TYPE void *
#endif
/* Holds the entire state of the reentrant scanner. */
struct yyguts_t
{
/* User-defined. Not touched by flex. */
YY_EXTRA_TYPE yyextra_r;
/* The rest are the same as the globals declared in the non-reentrant scanner. */
FILE *yyin_r, *yyout_r;
size_t yy_buffer_stack_top; /**< index of top of stack. */
size_t yy_buffer_stack_max; /**< capacity of stack. */
YY_BUFFER_STATE * yy_buffer_stack; /**< Stack as an array. */
char yy_hold_char;
int yy_n_chars;
int yyleng_r;
char *yy_c_buf_p;
int yy_init;
int yy_start;
int yy_did_buffer_switch_on_eof;
int yy_start_stack_ptr;
int yy_start_stack_depth;
int *yy_start_stack;
yy_state_type yy_last_accepting_state;
char* yy_last_accepting_cpos;
int yylineno_r;
int yy_flex_debug_r;
char *yytext_r;
int yy_more_flag;
int yy_more_len;
YYSTYPE * yylval_r;
YYLTYPE * yylloc_r;
}; /* end struct yyguts_t */
static int yy_init_globals (yyscan_t yyscanner );
/* This must go here because YYSTYPE and YYLTYPE are included
* from bison output in section 1.*/
# define yylval yyg->yylval_r
# define yylloc yyg->yylloc_r
int ael_yylex_init (yyscan_t* scanner);
int ael_yylex_init_extra (YY_EXTRA_TYPE user_defined,yyscan_t* scanner);
/* Accessor methods to globals.
These are made visible to non-reentrant scanners for convenience. */
int ael_yylex_destroy (yyscan_t yyscanner );
int ael_yyget_debug (yyscan_t yyscanner );
void ael_yyset_debug (int debug_flag ,yyscan_t yyscanner );
YY_EXTRA_TYPE ael_yyget_extra (yyscan_t yyscanner );
void ael_yyset_extra (YY_EXTRA_TYPE user_defined ,yyscan_t yyscanner );
FILE *ael_yyget_in (yyscan_t yyscanner );
void ael_yyset_in (FILE * in_str ,yyscan_t yyscanner );
FILE *ael_yyget_out (yyscan_t yyscanner );
void ael_yyset_out (FILE * out_str ,yyscan_t yyscanner );
int ael_yyget_leng (yyscan_t yyscanner );
char *ael_yyget_text (yyscan_t yyscanner );
int ael_yyget_lineno (yyscan_t yyscanner );
void ael_yyset_lineno (int line_number ,yyscan_t yyscanner );
YYSTYPE * ael_yyget_lval (yyscan_t yyscanner );
void ael_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
YYLTYPE *ael_yyget_lloc (yyscan_t yyscanner );
void ael_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner );
/* Macros after this point can all be overridden by user definitions in
* section 1.
*/
#ifndef YY_SKIP_YYWRAP
#ifdef __cplusplus
extern "C" int ael_yywrap (yyscan_t yyscanner );
#else
extern int ael_yywrap (yyscan_t yyscanner );
#endif
#endif
static void yyunput (int c,char *buf_ptr ,yyscan_t yyscanner);
#ifndef yytext_ptr
static void yy_flex_strncpy (char *,yyconst char *,int ,yyscan_t yyscanner);
#endif
#ifdef YY_NEED_STRLEN
static int yy_flex_strlen (yyconst char * ,yyscan_t yyscanner);
#endif
#ifndef YY_NO_INPUT
#ifdef __cplusplus
static int yyinput (yyscan_t yyscanner );
#else
static int input (yyscan_t yyscanner );
#endif
#endif
/* Amount of stuff to slurp up with each read. */
#ifndef YY_READ_BUF_SIZE
#ifdef __ia64__
/* On IA-64, the buffer size is 16k, not 8k */
#define YY_READ_BUF_SIZE 16384
#else
#define YY_READ_BUF_SIZE 8192
#endif /* __ia64__ */
#endif
/* Copy whatever the last rule matched to the standard output. */
#ifndef ECHO
/* This used to be an fputs(), but since the string might contain NUL's,
* we now use fwrite().
*/
#define ECHO do { if (fwrite( yytext, yyleng, 1, yyout )) {} } while (0)
#endif
/* Gets input and stuffs it into "buf". number of characters read, or YY_NULL,
* is returned in "result".
*/
#ifndef YY_INPUT
#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
size_t n; \
for ( n = 0; n < max_size && \
(c = getc( yyin )) != EOF && c != '\n'; ++n ) \
buf[n] = (char) c; \
if ( c == '\n' ) \
buf[n++] = (char) c; \
if ( c == EOF && ferror( yyin ) ) \
YY_FATAL_ERROR( "input in flex scanner failed" ); \
result = n; \
} \
else \
{ \
errno=0; \
while ( (result = fread(buf, 1, max_size, yyin))==0 && ferror(yyin)) \
{ \
if( errno != EINTR) \
{ \
YY_FATAL_ERROR( "input in flex scanner failed" ); \
break; \
} \
errno=0; \
clearerr(yyin); \
} \
}\
\
#endif
/* No semi-colon after return; correct usage is to write "yyterminate();" -
* we don't want an extra ';' after the "return" because that will cause
* some compilers to complain about unreachable statements.
*/
#ifndef yyterminate
#define yyterminate() return YY_NULL
#endif
/* Number of entries by which start-condition stack grows. */
#ifndef YY_START_STACK_INCR
#define YY_START_STACK_INCR 25
#endif
/* Report a fatal error. */
#ifndef YY_FATAL_ERROR
#define YY_FATAL_ERROR(msg) yy_fatal_error( msg , yyscanner)
#endif
/* end tables serialization structures and prototypes */
/* Default declaration of generated scanner - a define so the user can
* easily add parameters.
*/
#ifndef YY_DECL
#define YY_DECL_IS_OURS 1
extern int ael_yylex \
(YYSTYPE * yylval_param,YYLTYPE * yylloc_param ,yyscan_t yyscanner);
#define YY_DECL int ael_yylex \
(YYSTYPE * yylval_param, YYLTYPE * yylloc_param , yyscan_t yyscanner)
#endif /* !YY_DECL */
/* Code executed at the beginning of each rule, after yytext and yyleng
* have been set up.
*/
#ifndef YY_USER_ACTION
#define YY_USER_ACTION
#endif
/* Code executed at the end of each rule. */
#ifndef YY_BREAK
#define YY_BREAK break;
#endif
#define YY_RULE_SETUP \
YY_USER_ACTION
/** The main scanner function which does all the work.
*/
YY_DECL
{
register yy_state_type yy_current_state;
register char *yy_cp, *yy_bp;
register int yy_act;
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
#line 217 "ael.flex"
#line 1219 "ael_lex.c"
yylval = yylval_param;
yylloc = yylloc_param;
if ( !yyg->yy_init )
{
yyg->yy_init = 1;
#ifdef YY_USER_INIT
YY_USER_INIT;
#endif
if ( ! yyg->yy_start )
yyg->yy_start = 1; /* first start state */
if ( ! yyin )
yyin = stdin;
if ( ! yyout )
yyout = stdout;
if ( ! YY_CURRENT_BUFFER ) {
ael_yyensure_buffer_stack (yyscanner);
YY_CURRENT_BUFFER_LVALUE =
ael_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner);
}
ael_yy_load_buffer_state(yyscanner );
}
while ( 1 ) /* loops until end-of-file is reached */
{
yyg->yy_more_len = 0;
if ( yyg->yy_more_flag )
{
yyg->yy_more_len = yyg->yy_c_buf_p - yyg->yytext_ptr;
yyg->yy_more_flag = 0;
}
yy_cp = yyg->yy_c_buf_p;
/* Support of yytext. */
*yy_cp = yyg->yy_hold_char;
/* yy_bp points to the position in yy_ch_buf of the start of
* the current run.
*/
yy_bp = yy_cp;
yy_current_state = yyg->yy_start;
yy_match:
do
{
register YY_CHAR yy_c = yy_ec[YY_SC_TO_UI(*yy_cp)];
if ( yy_accept[yy_current_state] )
{
yyg->yy_last_accepting_state = yy_current_state;
yyg->yy_last_accepting_cpos = yy_cp;
}
while ( yy_chk[yy_base[yy_current_state] + yy_c] != yy_current_state )
{
yy_current_state = (int) yy_def[yy_current_state];
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
if ( yy_current_state >= 285 )
yy_c = yy_meta[(unsigned int) yy_c];
}
yy_current_state = yy_nxt[yy_base[yy_current_state] + (unsigned int) yy_c];
++yy_cp;
}
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
while ( yy_current_state != 284 );
yy_cp = yyg->yy_last_accepting_cpos;
yy_current_state = yyg->yy_last_accepting_state;
yy_find_action:
yy_act = yy_accept[yy_current_state];
YY_DO_BEFORE_ACTION;
do_action: /* This label is used only to access EOF actions. */
switch ( yy_act )
{ /* beginning of action switch */
case 0: /* must back up */
/* undo the effects of YY_DO_BEFORE_ACTION */
*yy_cp = yyg->yy_hold_char;
yy_cp = yyg->yy_last_accepting_cpos;
yy_current_state = yyg->yy_last_accepting_state;
goto yy_find_action;
case 1:
YY_RULE_SETUP
#line 219 "ael.flex"
{ STORE_POS; return LC;}
YY_BREAK
case 2:
YY_RULE_SETUP
#line 220 "ael.flex"
{ STORE_POS; return RC;}
YY_BREAK
case 3:
YY_RULE_SETUP
#line 221 "ael.flex"
{ STORE_POS; return LP;}
YY_BREAK
case 4:
YY_RULE_SETUP
#line 222 "ael.flex"
{ STORE_POS; return RP;}
YY_BREAK
case 5:
YY_RULE_SETUP
#line 223 "ael.flex"
{ STORE_POS; return SEMI;}
YY_BREAK
case 6:
YY_RULE_SETUP
#line 224 "ael.flex"
{ STORE_POS; return EQ;}
YY_BREAK
case 7:
YY_RULE_SETUP
#line 225 "ael.flex"
{ STORE_POS; return COMMA;}
YY_BREAK
case 8:
YY_RULE_SETUP
#line 226 "ael.flex"
{ STORE_POS; return COLON;}
YY_BREAK
case 9:
YY_RULE_SETUP
#line 227 "ael.flex"
{ STORE_POS; return AMPER;}
YY_BREAK
case 10:
YY_RULE_SETUP
#line 228 "ael.flex"
{ STORE_POS; return BAR;}
YY_BREAK
case 11:
YY_RULE_SETUP
#line 229 "ael.flex"
{ STORE_POS; return EXTENMARK;}
YY_BREAK
case 12:
YY_RULE_SETUP
#line 230 "ael.flex"
{ STORE_POS; return AT;}
YY_BREAK
case 13:
YY_RULE_SETUP
#line 231 "ael.flex"
{/*comment*/}
YY_BREAK
case 14:
YY_RULE_SETUP
#line 232 "ael.flex"
{ STORE_POS; return KW_CONTEXT;}
YY_BREAK
case 15:
YY_RULE_SETUP
#line 233 "ael.flex"
{ STORE_POS; return KW_ABSTRACT;}
YY_BREAK
case 16:
YY_RULE_SETUP
#line 234 "ael.flex"
{ STORE_POS; return KW_EXTEND;}
YY_BREAK
case 17:
YY_RULE_SETUP
#line 235 "ael.flex"
{ STORE_POS; return KW_MACRO;};
YY_BREAK
case 18:
YY_RULE_SETUP
#line 236 "ael.flex"
{ STORE_POS; return KW_GLOBALS;}
YY_BREAK
case 19:
YY_RULE_SETUP
#line 237 "ael.flex"
{ STORE_POS; return KW_LOCAL;}
YY_BREAK
case 20:
YY_RULE_SETUP
#line 238 "ael.flex"
{ STORE_POS; return KW_IGNOREPAT;}
YY_BREAK
case 21:
YY_RULE_SETUP
#line 239 "ael.flex"
{ STORE_POS; return KW_SWITCH;}
YY_BREAK
case 22:
YY_RULE_SETUP
#line 240 "ael.flex"
{ STORE_POS; return KW_IF;}
YY_BREAK
case 23:
YY_RULE_SETUP
#line 241 "ael.flex"
{ STORE_POS; return KW_IFTIME;}
YY_BREAK
case 24:
YY_RULE_SETUP
#line 242 "ael.flex"
{ STORE_POS; return KW_RANDOM;}
YY_BREAK
case 25:
YY_RULE_SETUP
#line 243 "ael.flex"
{ STORE_POS; return KW_REGEXTEN;}
YY_BREAK
case 26:
YY_RULE_SETUP
#line 244 "ael.flex"
{ STORE_POS; return KW_HINT;}
YY_BREAK
case 27:
YY_RULE_SETUP
#line 245 "ael.flex"
{ STORE_POS; return KW_ELSE;}
YY_BREAK
case 28:
YY_RULE_SETUP
#line 246 "ael.flex"
{ STORE_POS; return KW_GOTO;}
YY_BREAK
case 29:
YY_RULE_SETUP
#line 247 "ael.flex"
{ STORE_POS; return KW_JUMP;}
YY_BREAK
case 30:
YY_RULE_SETUP
#line 248 "ael.flex"
{ STORE_POS; return KW_RETURN;}
YY_BREAK
case 31:
YY_RULE_SETUP
#line 249 "ael.flex"
{ STORE_POS; return KW_BREAK;}
YY_BREAK
case 32:
YY_RULE_SETUP
#line 250 "ael.flex"
{ STORE_POS; return KW_CONTINUE;}
YY_BREAK
case 33:
YY_RULE_SETUP
#line 251 "ael.flex"
{ STORE_POS; return KW_FOR;}
YY_BREAK
case 34:
YY_RULE_SETUP
#line 252 "ael.flex"
{ STORE_POS; return KW_WHILE;}
YY_BREAK
case 35:
YY_RULE_SETUP
#line 253 "ael.flex"
{ STORE_POS; return KW_CASE;}
YY_BREAK
case 36:
YY_RULE_SETUP
#line 254 "ael.flex"
{ STORE_POS; return KW_DEFAULT;}
YY_BREAK
case 37:
YY_RULE_SETUP
#line 255 "ael.flex"
{ STORE_POS; return KW_PATTERN;}
YY_BREAK
case 38:
YY_RULE_SETUP
#line 256 "ael.flex"
{ STORE_POS; return KW_CATCH;}
YY_BREAK
case 39:
YY_RULE_SETUP
#line 257 "ael.flex"
{ STORE_POS; return KW_SWITCHES;}
YY_BREAK
case 40:
YY_RULE_SETUP
#line 258 "ael.flex"
{ STORE_POS; return KW_ESWITCHES;}
YY_BREAK
case 41:
YY_RULE_SETUP
#line 259 "ael.flex"
{ STORE_POS; return KW_INCLUDES;}
YY_BREAK
case 42:
YY_RULE_SETUP
#line 260 "ael.flex"
{ BEGIN(comment); my_col += 2; }
YY_BREAK
case 43:
YY_RULE_SETUP
#line 262 "ael.flex"
{ my_col += yyleng; }
YY_BREAK
case 44:
/* rule 44 can match eol */
YY_RULE_SETUP
#line 263 "ael.flex"
{ ++my_lineno; my_col=1;}
YY_BREAK
case 45:
YY_RULE_SETUP
#line 264 "ael.flex"
{ my_col += yyleng; }
YY_BREAK
case 46:
/* rule 46 can match eol */
YY_RULE_SETUP
#line 265 "ael.flex"
{ ++my_lineno; my_col=1;}
YY_BREAK
case 47:
YY_RULE_SETUP
#line 266 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{ my_col += 2; BEGIN(INITIAL); } /* the nice thing about comments is that you know exactly what ends them */
YY_BREAK
case 48:
/* rule 48 can match eol */
YY_RULE_SETUP
#line 268 "ael.flex"
{ my_lineno++; my_col = 1; }
YY_BREAK
case 49:
YY_RULE_SETUP
#line 269 "ael.flex"
{ my_col += yyleng; }
YY_BREAK
case 50:
YY_RULE_SETUP
#line 270 "ael.flex"
{ my_col += (yyleng*8)-(my_col%8); }
YY_BREAK
case 51:
YY_RULE_SETUP
#line 272 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{
/* boy did I open a can of worms when I changed the lexical token "word".
all the above keywords can be used as a beginning to a "word".-
before, a "word" would match a longer sequence than the above
keywords, and all would be well. But now "word" is a single char
and feeds into a statemachine sort of sequence from there on. So...
I added the {KEYWORD}? to the beginning of the word match sequence */
if (!strcmp(yytext,"${")) {
parencount2 = 0;
pbcpos2 = 0;
pbcpush2('{'); /* push '{' so the last pcbpop (parencount2 = -1) will succeed */
BEGIN(curlystate);
yymore();
} else if (!strcmp(yytext,"$[")) {
parencount3 = 0;
pbcpos3 = 0;
pbcpush3('['); /* push '[' so the last pcbpop (parencount3 = -1) will succeed */
BEGIN(brackstate);
yymore();
} else {
BEGIN(wordstate);
yymore();
}
}
YY_BREAK
case 52:
YY_RULE_SETUP
#line 298 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{ yymore(); /* Keep going */ }
YY_BREAK
case 53:
YY_RULE_SETUP
#line 299 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{ yymore(); /* Keep going */ }
YY_BREAK
case 54:
YY_RULE_SETUP
#line 300 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{ yymore(); /* Keep Going */ }
YY_BREAK
case 55:
YY_RULE_SETUP
#line 301 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{ /* the beginning of a ${} construct. prepare and pop into curlystate */
parencount2 = 0;
pbcpos2 = 0;
pbcpush2('{'); /* push '{' so the last pcbpop (parencount2 = -1) will succeed */
BEGIN(curlystate);
yymore();
}
YY_BREAK
case 56:
YY_RULE_SETUP
#line 308 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{ /* the beginning of a $[] construct. prepare and pop into brackstate */
parencount3 = 0;
pbcpos3 = 0;
pbcpush3('['); /* push '[' so the last pcbpop (parencount3 = -1) will succeed */
BEGIN(brackstate);
yymore();
}
YY_BREAK
case 57:
/* rule 57 can match eol */
YY_RULE_SETUP
#line 315 "ael.flex"
{
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
/* a non-word constituent char, like a space, tab, curly, paren, etc */
char c = yytext[yyleng-1];
STORE_POS;
yylval->str = malloc(yyleng);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng-1] = 0;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
unput(c); /* put this ending char back in the stream */
BEGIN(0);
return word;
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 58:
/* rule 58 can match eol */
YY_RULE_SETUP
#line 328 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{
if ( pbcpop2('}') ) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched ')' in expression: %s !\n", my_file, my_lineno, my_col, yytext);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = 0;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
return word;
}
parencount2--;
if ( parencount2 >= 0) {
yymore();
} else {
BEGIN(wordstate); /* Finished with the current ${} construct. Return to word gathering state */
yymore();
}
}
YY_BREAK
case 59:
/* rule 59 can match eol */
YY_RULE_SETUP
#line 347 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{
char c = yytext[yyleng-1];
if (c == '{')
parencount2++;
pbcpush2(c);
yymore();
}
YY_BREAK
case 60:
/* rule 60 can match eol */
YY_RULE_SETUP
#line 355 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{
char c = yytext[yyleng-1];
if ( pbcpop2(c)) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched '%c' in expression!\n",
my_file, my_lineno, my_col, c);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = 0;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
return word;
}
yymore();
}
YY_BREAK
case 61:
/* rule 61 can match eol */
YY_RULE_SETUP
#line 371 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{
if ( pbcpop3(']') ) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched ')' in expression: %s !\n", my_file, my_lineno, my_col, yytext);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = 0;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
return word;
}
parencount3--;
if ( parencount3 >= 0) {
yymore();
} else {
BEGIN(wordstate); /* Finished with the current ${} construct. Return to word gathering state */
yymore();
}
}
YY_BREAK
case 62:
/* rule 62 can match eol */
YY_RULE_SETUP
#line 390 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{
char c = yytext[yyleng-1];
if (c == '[')
parencount3++;
pbcpush3(c);
yymore();
}
YY_BREAK
case 63:
/* rule 63 can match eol */
YY_RULE_SETUP
#line 398 "ael.flex"
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
{
char c = yytext[yyleng-1];
if ( pbcpop3(c)) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched '%c' in expression!\n",
my_file, my_lineno, my_col, c);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = 0;
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
return word;
}
yymore();
}
YY_BREAK
/*
* context used for arguments of if_head, random_head, switch_head,
* for (last statement), while (XXX why not iftime_head ?).
* End with the matching parentheses.
* A comma at the top level is valid here, unlike in argg where it
* is an argument separator so it must be returned as a token.
*/
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 64:
/* rule 64 can match eol */
YY_RULE_SETUP
#line 421 "ael.flex"
{
if ( pbcpop(')') ) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched ')' in expression: %s !\n", my_file, my_lineno, my_col, yytext);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = 0;
prev_word = 0;
return word;
}
parencount--;
if ( parencount >= 0) {
yymore();
} else {
STORE_LOC;
yylval->str = malloc(yyleng);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng-1] = 0;
unput(')');
BEGIN(0);
return word;
}
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 65:
/* rule 65 can match eol */
YY_RULE_SETUP
#line 446 "ael.flex"
{
char c = yytext[yyleng-1];
if (c == '(')
parencount++;
pbcpush(c);
yymore();
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 66:
/* rule 66 can match eol */
YY_RULE_SETUP
#line 454 "ael.flex"
{
char c = yytext[yyleng-1];
if ( pbcpop(c)) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched '%c' in expression!\n",
my_file, my_lineno, my_col, c);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = 0;
return word;
}
yymore();
}
YY_BREAK
/*
* handlers for arguments to a macro or application calls.
* We enter this context when we find the initial '(' and
* stay here until we close all matching parentheses,
* and find the comma (argument separator) or the closing ')'
* of the (external) call, which happens when parencount == 0
* before the decrement.
*/
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 67:
/* rule 67 can match eol */
YY_RULE_SETUP
#line 478 "ael.flex"
{
char c = yytext[yyleng-1];
if (c == '(')
parencount++;
pbcpush(c);
yymore();
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 68:
/* rule 68 can match eol */
YY_RULE_SETUP
#line 486 "ael.flex"
{
if ( pbcpop(')') ) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched ')' in expression!\n", my_file, my_lineno, my_col);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = 0;
return word;
}
parencount--;
if( parencount >= 0){
yymore();
} else {
STORE_LOC;
BEGIN(0);
if ( !strcmp(yytext, ")") )
return RP;
yylval->str = malloc(yyleng);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng-1] = '\0'; /* trim trailing ')' */
unput(')');
return word;
}
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 69:
/* rule 69 can match eol */
YY_RULE_SETUP
#line 513 "ael.flex"
{
Merged revisions 162013 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r162013 | murf | 2008-12-09 09:31:55 -0700 (Tue, 09 Dec 2008) | 45 lines (closes issue #14019) Reported by: ckjohnsonme Patches: 14019.diff uploaded by murf (license 17) Tested by: ckjohnsonme, murf This crash was the result of a few small errors that would combine in 64-bit land to result in a crash. 32-bit land might have seen these combine to mysteriously drop the args to an application call, in certain circumstances. Also, in trying to find this bug, I spotted a situation in the flex input, where, in passing back a 'word' to the parser, it would allocate a buffer larger than necessary. I changed the usage in such situations, so that strdup was not used, but rather, an ast_malloc, followed by ast_copy_string. I removed a field from the pval struct, in u2, that was never getting used, and set in one spot in the code. I believe it was an artifact of a previous fix to make switch cases work invisibly with extens. And, for goto's I removed a '!' from before a strcmp, that has been there since the initial merging of AEL2, that might prevent the proper target of a goto from being found. This was pretty harmless on its own, as it would just louse up a consistency check for users. Many thanks to ckjohnsonme for providing a simplified and complete set of information about the bug, that helped considerably in finding and fixing the problem. Now, to get aelparse up and running again in trunk, and out of its "horribly broken" state, so I can run the regression suite! ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-09 17:18:03 +00:00
if( parencount != 0) { /* ast_log(LOG_NOTICE,"Folding in a comma!\n"); */
yymore();
} else {
STORE_LOC;
if( !strcmp(yytext,"," ) )
return COMMA;
yylval->str = malloc(yyleng);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng-1] = '\0'; /* trim trailing ',' */
unput(',');
return word;
}
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 70:
/* rule 70 can match eol */
YY_RULE_SETUP
#line 528 "ael.flex"
{
char c = yytext[yyleng-1];
if ( pbcpop(c) ) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched '%c' in expression!\n", my_file, my_lineno, my_col, c);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = '\0';
return word;
}
yymore();
}
YY_BREAK
/*
* context used to find tokens in the right hand side of assignments,
* or in the first and second operand of a 'for'. As above, match
* commas and use ';' as a separator (hence return it as a separate token).
*/
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 71:
/* rule 71 can match eol */
YY_RULE_SETUP
#line 547 "ael.flex"
{
char c = yytext[yyleng-1];
yymore();
pbcpush(c);
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 72:
/* rule 72 can match eol */
YY_RULE_SETUP
#line 553 "ael.flex"
{
char c = yytext[yyleng-1];
if ( pbcpop(c) ) { /* error */
STORE_LOC;
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Mismatched '%c' in expression!\n", my_file, my_lineno, my_col, c);
BEGIN(0);
yylval->str = malloc(yyleng+1);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng] = '\0';
return word;
}
yymore();
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 73:
/* rule 73 can match eol */
YY_RULE_SETUP
#line 567 "ael.flex"
{
STORE_LOC;
yylval->str = malloc(yyleng);
strncpy(yylval->str, yytext, yyleng);
yylval->str[yyleng-1] = '\0'; /* trim trailing ';' */
unput(';');
BEGIN(0);
return word;
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 74:
/* rule 74 can match eol */
YY_RULE_SETUP
#line 577 "ael.flex"
{
char fnamebuf[1024],*p1,*p2;
int glob_ret;
glob_t globbuf; /* the current globbuf */
int globbuf_pos = -1; /* where we are in the current globbuf */
globbuf.gl_offs = 0; /* initialize it to silence gcc */
p1 = strchr(yytext,'"');
p2 = strrchr(yytext,'"');
if ( include_stack_index >= MAX_INCLUDE_DEPTH ) {
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Includes nested too deeply! Wow!!! How did you do that?\n", my_file, my_lineno, my_col);
} else if ( (int)(p2-p1) > sizeof(fnamebuf) - 1 ) {
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Filename is incredibly way too long (%d chars!). Inclusion ignored!\n", my_file, my_lineno, my_col, yyleng - 10);
} else {
strncpy(fnamebuf, p1+1, p2-p1-1);
fnamebuf[p2-p1-1] = 0;
if (fnamebuf[0] != '/') {
char fnamebuf2[1024];
snprintf(fnamebuf2,sizeof(fnamebuf2), "%s/%s", (char *)ast_config_AST_CONFIG_DIR, fnamebuf);
ast_copy_string(fnamebuf,fnamebuf2,sizeof(fnamebuf));
}
#ifdef SOLARIS
glob_ret = glob(fnamebuf, GLOB_NOCHECK, NULL, &globbuf);
#else
glob_ret = glob(fnamebuf, GLOB_NOMAGIC|GLOB_BRACE, NULL, &globbuf);
#endif
if (glob_ret == GLOB_NOSPACE) {
ast_log(LOG_WARNING,
"Glob Expansion of pattern '%s' failed: Not enough memory\n", fnamebuf);
} else if (glob_ret == GLOB_ABORTED) {
ast_log(LOG_WARNING,
"Glob Expansion of pattern '%s' failed: Read error\n", fnamebuf);
} else if (glob_ret == GLOB_NOMATCH) {
ast_log(LOG_WARNING,
"Glob Expansion of pattern '%s' failed: No matches!\n", fnamebuf);
} else {
globbuf_pos = 0;
}
}
if (globbuf_pos > -1) {
setup_filestack(fnamebuf, sizeof(fnamebuf), &globbuf, 0, yyscanner, 1);
}
}
YY_BREAK
case YY_STATE_EOF(INITIAL):
case YY_STATE_EOF(paren):
case YY_STATE_EOF(semic):
case YY_STATE_EOF(argg):
case YY_STATE_EOF(comment):
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case YY_STATE_EOF(curlystate):
case YY_STATE_EOF(wordstate):
case YY_STATE_EOF(brackstate):
#line 622 "ael.flex"
{
char fnamebuf[2048];
if (include_stack_index > 0 && include_stack[include_stack_index-1].globbuf_pos < include_stack[include_stack_index-1].globbuf.gl_pathc-1) {
ael_yy_delete_buffer(YY_CURRENT_BUFFER,yyscanner );
include_stack[include_stack_index-1].globbuf_pos++;
setup_filestack(fnamebuf, sizeof(fnamebuf), &include_stack[include_stack_index-1].globbuf, include_stack[include_stack_index-1].globbuf_pos, yyscanner, 0);
/* finish this */
} else {
if (include_stack[include_stack_index].fname) {
free(include_stack[include_stack_index].fname);
include_stack[include_stack_index].fname = 0;
}
if (my_file) {
free(my_file);
my_file = 0;
}
if ( --include_stack_index < 0 ) {
yyterminate();
} else {
globfree(&include_stack[include_stack_index].globbuf);
include_stack[include_stack_index].globbuf_pos = -1;
ael_yy_delete_buffer(YY_CURRENT_BUFFER,yyscanner );
ael_yy_switch_to_buffer(include_stack[include_stack_index].bufstate,yyscanner );
my_lineno = include_stack[include_stack_index].lineno;
my_col = include_stack[include_stack_index].colno;
my_file = strdup(include_stack[include_stack_index].fname);
}
}
}
YY_BREAK
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
case 75:
/* rule 75 can match eol */
YY_RULE_SETUP
#line 654 "ael.flex"
{ /* default rule */ ast_log(LOG_ERROR,"Unhandled char(s): %s\n", yytext); }
YY_BREAK
case 76:
YY_RULE_SETUP
#line 656 "ael.flex"
YY_FATAL_ERROR( "flex scanner jammed" );
YY_BREAK
#line 2053 "ael_lex.c"
case YY_END_OF_BUFFER:
{
/* Amount of text matched not including the EOB char. */
int yy_amount_of_matched_text = (int) (yy_cp - yyg->yytext_ptr) - 1;
/* Undo the effects of YY_DO_BEFORE_ACTION. */
*yy_cp = yyg->yy_hold_char;
YY_RESTORE_YY_MORE_OFFSET
if ( YY_CURRENT_BUFFER_LVALUE->yy_buffer_status == YY_BUFFER_NEW )
{
/* We're scanning a new file or input source. It's
* possible that this happened because the user
* just pointed yyin at a new source and called
* ael_yylex(). If so, then we have to assure
* consistency between YY_CURRENT_BUFFER and our
* globals. Here is the right place to do so, because
* this is the first action (other than possibly a
* back-up) that will match for the new input source.
*/
yyg->yy_n_chars = YY_CURRENT_BUFFER_LVALUE->yy_n_chars;
YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;
YY_CURRENT_BUFFER_LVALUE->yy_buffer_status = YY_BUFFER_NORMAL;
}
/* Note that here we test for yy_c_buf_p "<=" to the position
* of the first EOB in the buffer, since yy_c_buf_p will
* already have been incremented past the NUL character
* (since all states make transitions on EOB to the
* end-of-buffer state). Contrast this with the test
* in input().
*/
if ( yyg->yy_c_buf_p <= &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[yyg->yy_n_chars] )
{ /* This was really a NUL. */
yy_state_type yy_next_state;
yyg->yy_c_buf_p = yyg->yytext_ptr + yy_amount_of_matched_text;
yy_current_state = yy_get_previous_state( yyscanner );
/* Okay, we're now positioned to make the NUL
* transition. We couldn't have
* yy_get_previous_state() go ahead and do it
* for us because it doesn't know how to deal
* with the possibility of jamming (and we don't
* want to build jamming into it because then it
* will run more slowly).
*/
yy_next_state = yy_try_NUL_trans( yy_current_state , yyscanner);
yy_bp = yyg->yytext_ptr + YY_MORE_ADJ;
if ( yy_next_state )
{
/* Consume the NUL. */
yy_cp = ++yyg->yy_c_buf_p;
yy_current_state = yy_next_state;
goto yy_match;
}
else
{
yy_cp = yyg->yy_last_accepting_cpos;
yy_current_state = yyg->yy_last_accepting_state;
goto yy_find_action;
}
}
else switch ( yy_get_next_buffer( yyscanner ) )
{
case EOB_ACT_END_OF_FILE:
{
yyg->yy_did_buffer_switch_on_eof = 0;
if ( ael_yywrap(yyscanner ) )
{
/* Note: because we've taken care in
* yy_get_next_buffer() to have set up
* yytext, we can now set up
* yy_c_buf_p so that if some total
* hoser (like flex itself) wants to
* call the scanner after we return the
* YY_NULL, it'll still work - another
* YY_NULL will get returned.
*/
yyg->yy_c_buf_p = yyg->yytext_ptr + YY_MORE_ADJ;
yy_act = YY_STATE_EOF(YY_START);
goto do_action;
}
else
{
if ( ! yyg->yy_did_buffer_switch_on_eof )
YY_NEW_FILE;
}
break;
}
case EOB_ACT_CONTINUE_SCAN:
yyg->yy_c_buf_p =
yyg->yytext_ptr + yy_amount_of_matched_text;
yy_current_state = yy_get_previous_state( yyscanner );
yy_cp = yyg->yy_c_buf_p;
yy_bp = yyg->yytext_ptr + YY_MORE_ADJ;
goto yy_match;
case EOB_ACT_LAST_MATCH:
yyg->yy_c_buf_p =
&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[yyg->yy_n_chars];
yy_current_state = yy_get_previous_state( yyscanner );
yy_cp = yyg->yy_c_buf_p;
yy_bp = yyg->yytext_ptr + YY_MORE_ADJ;
goto yy_find_action;
}
break;
}
default:
YY_FATAL_ERROR(
"fatal flex scanner internal error--no action found" );
} /* end of action switch */
} /* end of scanning one token */
} /* end of ael_yylex */
/* yy_get_next_buffer - try to read in a new buffer
*
* Returns a code representing an action:
* EOB_ACT_LAST_MATCH -
* EOB_ACT_CONTINUE_SCAN - continue scanning from current position
* EOB_ACT_END_OF_FILE - end of file
*/
static int yy_get_next_buffer (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
register char *dest = YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
register char *source = yyg->yytext_ptr;
register int number_to_move, i;
int ret_val;
if ( yyg->yy_c_buf_p > &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[yyg->yy_n_chars + 1] )
YY_FATAL_ERROR(
"fatal flex scanner internal error--end of buffer missed" );
if ( YY_CURRENT_BUFFER_LVALUE->yy_fill_buffer == 0 )
{ /* Don't try to fill the buffer, so this is an EOF. */
if ( yyg->yy_c_buf_p - yyg->yytext_ptr - YY_MORE_ADJ == 1 )
{
/* We matched a single character, the EOB, so
* treat this as a final EOF.
*/
return EOB_ACT_END_OF_FILE;
}
else
{
/* We matched some text prior to the EOB, first
* process it.
*/
return EOB_ACT_LAST_MATCH;
}
}
/* Try to read more data. */
/* First move last chars to start of buffer. */
number_to_move = (int) (yyg->yy_c_buf_p - yyg->yytext_ptr) - 1;
for ( i = 0; i < number_to_move; ++i )
*(dest++) = *(source++);
if ( YY_CURRENT_BUFFER_LVALUE->yy_buffer_status == YY_BUFFER_EOF_PENDING )
/* don't do the read, it's not guaranteed to return an EOF,
* just force an EOF
*/
YY_CURRENT_BUFFER_LVALUE->yy_n_chars = yyg->yy_n_chars = 0;
else
{
int num_to_read =
YY_CURRENT_BUFFER_LVALUE->yy_buf_size - number_to_move - 1;
while ( num_to_read <= 0 )
{ /* Not enough room in the buffer - grow it. */
/* just a shorter name for the current buffer */
YY_BUFFER_STATE b = YY_CURRENT_BUFFER;
int yy_c_buf_p_offset =
(int) (yyg->yy_c_buf_p - b->yy_ch_buf);
if ( b->yy_is_our_buffer )
{
int new_size = b->yy_buf_size * 2;
if ( new_size <= 0 )
b->yy_buf_size += b->yy_buf_size / 8;
else
b->yy_buf_size *= 2;
b->yy_ch_buf = (char *)
/* Include room in for 2 EOB chars. */
ael_yyrealloc((void *) b->yy_ch_buf,b->yy_buf_size + 2 ,yyscanner );
}
else
/* Can't grow it, we don't own it. */
b->yy_ch_buf = 0;
if ( ! b->yy_ch_buf )
YY_FATAL_ERROR(
"fatal error - scanner input buffer overflow" );
yyg->yy_c_buf_p = &b->yy_ch_buf[yy_c_buf_p_offset];
num_to_read = YY_CURRENT_BUFFER_LVALUE->yy_buf_size -
number_to_move - 1;
}
if ( num_to_read > YY_READ_BUF_SIZE )
num_to_read = YY_READ_BUF_SIZE;
/* Read in more data. */
YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
yyg->yy_n_chars, (size_t) num_to_read );
YY_CURRENT_BUFFER_LVALUE->yy_n_chars = yyg->yy_n_chars;
}
if ( yyg->yy_n_chars == 0 )
{
if ( number_to_move == YY_MORE_ADJ )
{
ret_val = EOB_ACT_END_OF_FILE;
ael_yyrestart(yyin ,yyscanner);
}
else
{
ret_val = EOB_ACT_LAST_MATCH;
YY_CURRENT_BUFFER_LVALUE->yy_buffer_status =
YY_BUFFER_EOF_PENDING;
}
}
else
ret_val = EOB_ACT_CONTINUE_SCAN;
if ((yy_size_t) (yyg->yy_n_chars + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
/* Extend the array by 50%, plus the number we really need. */
yy_size_t new_size = yyg->yy_n_chars + number_to_move + (yyg->yy_n_chars >> 1);
YY_CURRENT_BUFFER_LVALUE->yy_ch_buf = (char *) ael_yyrealloc((void *) YY_CURRENT_BUFFER_LVALUE->yy_ch_buf,new_size ,yyscanner );
if ( ! YY_CURRENT_BUFFER_LVALUE->yy_ch_buf )
YY_FATAL_ERROR( "out of dynamic memory in yy_get_next_buffer()" );
}
yyg->yy_n_chars += number_to_move;
YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[yyg->yy_n_chars] = YY_END_OF_BUFFER_CHAR;
YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[yyg->yy_n_chars + 1] = YY_END_OF_BUFFER_CHAR;
yyg->yytext_ptr = &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[0];
return ret_val;
}
/* yy_get_previous_state - get the state just before the EOB char was reached */
static yy_state_type yy_get_previous_state (yyscan_t yyscanner)
{
register yy_state_type yy_current_state;
register char *yy_cp;
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yy_current_state = yyg->yy_start;
for ( yy_cp = yyg->yytext_ptr + YY_MORE_ADJ; yy_cp < yyg->yy_c_buf_p; ++yy_cp )
{
register YY_CHAR yy_c = (*yy_cp ? yy_ec[YY_SC_TO_UI(*yy_cp)] : 1);
if ( yy_accept[yy_current_state] )
{
yyg->yy_last_accepting_state = yy_current_state;
yyg->yy_last_accepting_cpos = yy_cp;
}
while ( yy_chk[yy_base[yy_current_state] + yy_c] != yy_current_state )
{
yy_current_state = (int) yy_def[yy_current_state];
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
if ( yy_current_state >= 285 )
yy_c = yy_meta[(unsigned int) yy_c];
}
yy_current_state = yy_nxt[yy_base[yy_current_state] + (unsigned int) yy_c];
}
return yy_current_state;
}
/* yy_try_NUL_trans - try to make a transition on the NUL character
*
* synopsis
* next_state = yy_try_NUL_trans( current_state );
*/
static yy_state_type yy_try_NUL_trans (yy_state_type yy_current_state , yyscan_t yyscanner)
{
register int yy_is_jam;
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* This var may be unused depending upon options. */
register char *yy_cp = yyg->yy_c_buf_p;
register YY_CHAR yy_c = 1;
if ( yy_accept[yy_current_state] )
{
yyg->yy_last_accepting_state = yy_current_state;
yyg->yy_last_accepting_cpos = yy_cp;
}
while ( yy_chk[yy_base[yy_current_state] + yy_c] != yy_current_state )
{
yy_current_state = (int) yy_def[yy_current_state];
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
if ( yy_current_state >= 285 )
yy_c = yy_meta[(unsigned int) yy_c];
}
yy_current_state = yy_nxt[yy_base[yy_current_state] + (unsigned int) yy_c];
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
yy_is_jam = (yy_current_state == 284);
return yy_is_jam ? 0 : yy_current_state;
}
static void yyunput (int c, register char * yy_bp , yyscan_t yyscanner)
{
register char *yy_cp;
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yy_cp = yyg->yy_c_buf_p;
/* undo effects of setting up yytext */
*yy_cp = yyg->yy_hold_char;
if ( yy_cp < YY_CURRENT_BUFFER_LVALUE->yy_ch_buf + 2 )
{ /* need to shift things up to make room */
/* +2 for EOB chars. */
register int number_to_move = yyg->yy_n_chars + 2;
register char *dest = &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[
YY_CURRENT_BUFFER_LVALUE->yy_buf_size + 2];
register char *source =
&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move];
while ( source > YY_CURRENT_BUFFER_LVALUE->yy_ch_buf )
*--dest = *--source;
yy_cp += (int) (dest - source);
yy_bp += (int) (dest - source);
YY_CURRENT_BUFFER_LVALUE->yy_n_chars =
yyg->yy_n_chars = YY_CURRENT_BUFFER_LVALUE->yy_buf_size;
if ( yy_cp < YY_CURRENT_BUFFER_LVALUE->yy_ch_buf + 2 )
YY_FATAL_ERROR( "flex scanner push-back overflow" );
}
*--yy_cp = (char) c;
yyg->yytext_ptr = yy_bp;
yyg->yy_hold_char = *yy_cp;
yyg->yy_c_buf_p = yy_cp;
}
#ifndef YY_NO_INPUT
#ifdef __cplusplus
static int yyinput (yyscan_t yyscanner)
#else
static int input (yyscan_t yyscanner)
#endif
{
int c;
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
*yyg->yy_c_buf_p = yyg->yy_hold_char;
if ( *yyg->yy_c_buf_p == YY_END_OF_BUFFER_CHAR )
{
/* yy_c_buf_p now points to the character we want to return.
* If this occurs *before* the EOB characters, then it's a
* valid NUL; if not, then we've hit the end of the buffer.
*/
if ( yyg->yy_c_buf_p < &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[yyg->yy_n_chars] )
/* This was really a NUL. */
*yyg->yy_c_buf_p = '\0';
else
{ /* need more input */
int offset = yyg->yy_c_buf_p - yyg->yytext_ptr;
++yyg->yy_c_buf_p;
switch ( yy_get_next_buffer( yyscanner ) )
{
case EOB_ACT_LAST_MATCH:
/* This happens because yy_g_n_b()
* sees that we've accumulated a
* token and flags that we need to
* try matching the token before
* proceeding. But for input(),
* there's no matching to consider.
* So convert the EOB_ACT_LAST_MATCH
* to EOB_ACT_END_OF_FILE.
*/
/* Reset buffer status. */
ael_yyrestart(yyin ,yyscanner);
/*FALLTHROUGH*/
case EOB_ACT_END_OF_FILE:
{
if ( ael_yywrap(yyscanner ) )
return EOF;
if ( ! yyg->yy_did_buffer_switch_on_eof )
YY_NEW_FILE;
#ifdef __cplusplus
return yyinput(yyscanner);
#else
return input(yyscanner);
#endif
}
case EOB_ACT_CONTINUE_SCAN:
yyg->yy_c_buf_p = yyg->yytext_ptr + offset;
break;
}
}
}
c = *(unsigned char *) yyg->yy_c_buf_p; /* cast for 8-bit char's */
*yyg->yy_c_buf_p = '\0'; /* preserve yytext */
yyg->yy_hold_char = *++yyg->yy_c_buf_p;
return c;
}
#endif /* ifndef YY_NO_INPUT */
/** Immediately switch to a different input stream.
* @param input_file A readable stream.
* @param yyscanner The scanner object.
* @note This function does not reset the start condition to @c INITIAL .
*/
void ael_yyrestart (FILE * input_file , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if ( ! YY_CURRENT_BUFFER ){
ael_yyensure_buffer_stack (yyscanner);
YY_CURRENT_BUFFER_LVALUE =
ael_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner);
}
ael_yy_init_buffer(YY_CURRENT_BUFFER,input_file ,yyscanner);
ael_yy_load_buffer_state(yyscanner );
}
/** Switch to a different input buffer.
* @param new_buffer The new input buffer.
* @param yyscanner The scanner object.
*/
void ael_yy_switch_to_buffer (YY_BUFFER_STATE new_buffer , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
/* TODO. We should be able to replace this entire function body
* with
* ael_yypop_buffer_state();
* ael_yypush_buffer_state(new_buffer);
*/
ael_yyensure_buffer_stack (yyscanner);
if ( YY_CURRENT_BUFFER == new_buffer )
return;
if ( YY_CURRENT_BUFFER )
{
/* Flush out information for old buffer. */
*yyg->yy_c_buf_p = yyg->yy_hold_char;
YY_CURRENT_BUFFER_LVALUE->yy_buf_pos = yyg->yy_c_buf_p;
YY_CURRENT_BUFFER_LVALUE->yy_n_chars = yyg->yy_n_chars;
}
YY_CURRENT_BUFFER_LVALUE = new_buffer;
ael_yy_load_buffer_state(yyscanner );
/* We don't actually know whether we did this switch during
* EOF (ael_yywrap()) processing, but the only time this flag
* is looked at is after ael_yywrap() is called, so it's safe
* to go ahead and always set it.
*/
yyg->yy_did_buffer_switch_on_eof = 1;
}
static void ael_yy_load_buffer_state (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yyg->yy_n_chars = YY_CURRENT_BUFFER_LVALUE->yy_n_chars;
yyg->yytext_ptr = yyg->yy_c_buf_p = YY_CURRENT_BUFFER_LVALUE->yy_buf_pos;
yyin = YY_CURRENT_BUFFER_LVALUE->yy_input_file;
yyg->yy_hold_char = *yyg->yy_c_buf_p;
}
/** Allocate and initialize an input buffer state.
* @param file A readable stream.
* @param size The character buffer size in bytes. When in doubt, use @c YY_BUF_SIZE.
* @param yyscanner The scanner object.
* @return the allocated buffer state.
*/
YY_BUFFER_STATE ael_yy_create_buffer (FILE * file, int size , yyscan_t yyscanner)
{
YY_BUFFER_STATE b;
b = (YY_BUFFER_STATE) ael_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner );
if ( ! b )
YY_FATAL_ERROR( "out of dynamic memory in ael_yy_create_buffer()" );
b->yy_buf_size = size;
/* yy_ch_buf has to be 2 characters longer than the size given because
* we need to put in 2 end-of-buffer characters.
*/
b->yy_ch_buf = (char *) ael_yyalloc(b->yy_buf_size + 2 ,yyscanner );
if ( ! b->yy_ch_buf )
YY_FATAL_ERROR( "out of dynamic memory in ael_yy_create_buffer()" );
b->yy_is_our_buffer = 1;
ael_yy_init_buffer(b,file ,yyscanner);
return b;
}
/** Destroy the buffer.
* @param b a buffer created with ael_yy_create_buffer()
* @param yyscanner The scanner object.
*/
void ael_yy_delete_buffer (YY_BUFFER_STATE b , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if ( ! b )
return;
if ( b == YY_CURRENT_BUFFER ) /* Not sure if we should pop here. */
YY_CURRENT_BUFFER_LVALUE = (YY_BUFFER_STATE) 0;
if ( b->yy_is_our_buffer )
ael_yyfree((void *) b->yy_ch_buf ,yyscanner );
ael_yyfree((void *) b ,yyscanner );
}
#ifndef __cplusplus
extern int isatty (int );
#endif /* __cplusplus */
/* Initializes or reinitializes a buffer.
* This function is sometimes called more than once on the same buffer,
* such as during a ael_yyrestart() or at EOF.
*/
static void ael_yy_init_buffer (YY_BUFFER_STATE b, FILE * file , yyscan_t yyscanner)
{
int oerrno = errno;
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
ael_yy_flush_buffer(b ,yyscanner);
b->yy_input_file = file;
b->yy_fill_buffer = 1;
/* If b is the current buffer, then ael_yy_init_buffer was _probably_
* called from ael_yyrestart() or through yy_get_next_buffer.
* In that case, we don't want to reset the lineno or column.
*/
if (b != YY_CURRENT_BUFFER){
b->yy_bs_lineno = 1;
b->yy_bs_column = 0;
}
b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
errno = oerrno;
}
/** Discard all buffered characters. On the next scan, YY_INPUT will be called.
* @param b the buffer state to be flushed, usually @c YY_CURRENT_BUFFER.
* @param yyscanner The scanner object.
*/
void ael_yy_flush_buffer (YY_BUFFER_STATE b , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if ( ! b )
return;
b->yy_n_chars = 0;
/* We always need two end-of-buffer characters. The first causes
* a transition to the end-of-buffer state. The second causes
* a jam in that state.
*/
b->yy_ch_buf[0] = YY_END_OF_BUFFER_CHAR;
b->yy_ch_buf[1] = YY_END_OF_BUFFER_CHAR;
b->yy_buf_pos = &b->yy_ch_buf[0];
b->yy_at_bol = 1;
b->yy_buffer_status = YY_BUFFER_NEW;
if ( b == YY_CURRENT_BUFFER )
ael_yy_load_buffer_state(yyscanner );
}
/** Pushes the new state onto the stack. The new state becomes
* the current state. This function will allocate the stack
* if necessary.
* @param new_buffer The new state.
* @param yyscanner The scanner object.
*/
void ael_yypush_buffer_state (YY_BUFFER_STATE new_buffer , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if (new_buffer == NULL)
return;
ael_yyensure_buffer_stack(yyscanner);
/* This block is copied from ael_yy_switch_to_buffer. */
if ( YY_CURRENT_BUFFER )
{
/* Flush out information for old buffer. */
*yyg->yy_c_buf_p = yyg->yy_hold_char;
YY_CURRENT_BUFFER_LVALUE->yy_buf_pos = yyg->yy_c_buf_p;
YY_CURRENT_BUFFER_LVALUE->yy_n_chars = yyg->yy_n_chars;
}
/* Only push if top exists. Otherwise, replace top. */
if (YY_CURRENT_BUFFER)
yyg->yy_buffer_stack_top++;
YY_CURRENT_BUFFER_LVALUE = new_buffer;
/* copied from ael_yy_switch_to_buffer. */
ael_yy_load_buffer_state(yyscanner );
yyg->yy_did_buffer_switch_on_eof = 1;
}
/** Removes and deletes the top of the stack, if present.
* The next element becomes the new top.
* @param yyscanner The scanner object.
*/
void ael_yypop_buffer_state (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if (!YY_CURRENT_BUFFER)
return;
ael_yy_delete_buffer(YY_CURRENT_BUFFER ,yyscanner);
YY_CURRENT_BUFFER_LVALUE = NULL;
if (yyg->yy_buffer_stack_top > 0)
--yyg->yy_buffer_stack_top;
if (YY_CURRENT_BUFFER) {
ael_yy_load_buffer_state(yyscanner );
yyg->yy_did_buffer_switch_on_eof = 1;
}
}
/* Allocates the stack if it does not exist.
* Guarantees space for at least one push.
*/
static void ael_yyensure_buffer_stack (yyscan_t yyscanner)
{
int num_to_alloc;
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if (!yyg->yy_buffer_stack) {
/* First allocation is just for 2 elements, since we don't know if this
* scanner will even need a stack. We use 2 instead of 1 to avoid an
* immediate realloc on the next call.
*/
num_to_alloc = 1;
yyg->yy_buffer_stack = (struct yy_buffer_state**)ael_yyalloc
(num_to_alloc * sizeof(struct yy_buffer_state*)
, yyscanner);
if ( ! yyg->yy_buffer_stack )
YY_FATAL_ERROR( "out of dynamic memory in ael_yyensure_buffer_stack()" );
memset(yyg->yy_buffer_stack, 0, num_to_alloc * sizeof(struct yy_buffer_state*));
yyg->yy_buffer_stack_max = num_to_alloc;
yyg->yy_buffer_stack_top = 0;
return;
}
if (yyg->yy_buffer_stack_top >= (yyg->yy_buffer_stack_max) - 1){
/* Increase the buffer to prepare for a possible push. */
int grow_size = 8 /* arbitrary grow size */;
num_to_alloc = yyg->yy_buffer_stack_max + grow_size;
yyg->yy_buffer_stack = (struct yy_buffer_state**)ael_yyrealloc
(yyg->yy_buffer_stack,
num_to_alloc * sizeof(struct yy_buffer_state*)
, yyscanner);
if ( ! yyg->yy_buffer_stack )
YY_FATAL_ERROR( "out of dynamic memory in ael_yyensure_buffer_stack()" );
/* zero only the new slots.*/
memset(yyg->yy_buffer_stack + yyg->yy_buffer_stack_max, 0, grow_size * sizeof(struct yy_buffer_state*));
yyg->yy_buffer_stack_max = num_to_alloc;
}
}
/** Setup the input buffer state to scan directly from a user-specified character buffer.
* @param base the character buffer
* @param size the size in bytes of the character buffer
* @param yyscanner The scanner object.
* @return the newly allocated buffer state object.
*/
YY_BUFFER_STATE ael_yy_scan_buffer (char * base, yy_size_t size , yyscan_t yyscanner)
{
YY_BUFFER_STATE b;
if ( size < 2 ||
base[size-2] != YY_END_OF_BUFFER_CHAR ||
base[size-1] != YY_END_OF_BUFFER_CHAR )
/* They forgot to leave room for the EOB's. */
return 0;
b = (YY_BUFFER_STATE) ael_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner );
if ( ! b )
YY_FATAL_ERROR( "out of dynamic memory in ael_yy_scan_buffer()" );
b->yy_buf_size = size - 2; /* "- 2" to take care of EOB's */
b->yy_buf_pos = b->yy_ch_buf = base;
b->yy_is_our_buffer = 0;
b->yy_input_file = 0;
b->yy_n_chars = b->yy_buf_size;
b->yy_is_interactive = 0;
b->yy_at_bol = 1;
b->yy_fill_buffer = 0;
b->yy_buffer_status = YY_BUFFER_NEW;
ael_yy_switch_to_buffer(b ,yyscanner );
return b;
}
/** Setup the input buffer state to scan a string. The next call to ael_yylex() will
* scan from a @e copy of @a str.
* @param yystr a NUL-terminated string to scan
* @param yyscanner The scanner object.
* @return the newly allocated buffer state object.
* @note If you want to scan bytes that may contain NUL values, then use
* ael_yy_scan_bytes() instead.
*/
YY_BUFFER_STATE ael_yy_scan_string (yyconst char * yystr , yyscan_t yyscanner)
{
return ael_yy_scan_bytes(yystr,strlen(yystr) ,yyscanner);
}
/** Setup the input buffer state to scan the given bytes. The next call to ael_yylex() will
* scan from a @e copy of @a bytes.
* @param yybytes the byte buffer to scan
* @param _yybytes_len the number of bytes in the buffer pointed to by @a bytes.
* @param yyscanner The scanner object.
* @return the newly allocated buffer state object.
*/
YY_BUFFER_STATE ael_yy_scan_bytes (yyconst char * yybytes, int _yybytes_len , yyscan_t yyscanner)
{
YY_BUFFER_STATE b;
char *buf;
yy_size_t n;
int i;
/* Get memory for full buffer, including space for trailing EOB's. */
n = _yybytes_len + 2;
buf = (char *) ael_yyalloc(n ,yyscanner );
if ( ! buf )
YY_FATAL_ERROR( "out of dynamic memory in ael_yy_scan_bytes()" );
for ( i = 0; i < _yybytes_len; ++i )
buf[i] = yybytes[i];
buf[_yybytes_len] = buf[_yybytes_len+1] = YY_END_OF_BUFFER_CHAR;
b = ael_yy_scan_buffer(buf,n ,yyscanner);
if ( ! b )
YY_FATAL_ERROR( "bad buffer in ael_yy_scan_bytes()" );
/* It's okay to grow etc. this buffer, and we should throw it
* away when we're done.
*/
b->yy_is_our_buffer = 1;
return b;
}
#ifndef YY_EXIT_FAILURE
#define YY_EXIT_FAILURE 2
#endif
static void yy_fatal_error (yyconst char* msg , yyscan_t yyscanner)
{
(void) fprintf( stderr, "%s\n", msg );
exit( YY_EXIT_FAILURE );
}
/* Redefine yyless() so it works in section 3 code. */
#undef yyless
#define yyless(n) \
do \
{ \
/* Undo effects of setting up yytext. */ \
int yyless_macro_arg = (n); \
YY_LESS_LINENO(yyless_macro_arg);\
yytext[yyleng] = yyg->yy_hold_char; \
yyg->yy_c_buf_p = yytext + yyless_macro_arg; \
yyg->yy_hold_char = *yyg->yy_c_buf_p; \
*yyg->yy_c_buf_p = '\0'; \
yyleng = yyless_macro_arg; \
} \
while ( 0 )
/* Accessor methods (get/set functions) to struct members. */
/** Get the user-defined data for this scanner.
* @param yyscanner The scanner object.
*/
YY_EXTRA_TYPE ael_yyget_extra (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yyextra;
}
/** Get the current line number.
* @param yyscanner The scanner object.
*/
int ael_yyget_lineno (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if (! YY_CURRENT_BUFFER)
return 0;
return yylineno;
}
/** Get the current column number.
* @param yyscanner The scanner object.
*/
int ael_yyget_column (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
if (! YY_CURRENT_BUFFER)
return 0;
return yycolumn;
}
/** Get the input stream.
* @param yyscanner The scanner object.
*/
FILE *ael_yyget_in (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yyin;
}
/** Get the output stream.
* @param yyscanner The scanner object.
*/
FILE *ael_yyget_out (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yyout;
}
/** Get the length of the current token.
* @param yyscanner The scanner object.
*/
int ael_yyget_leng (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yyleng;
}
/** Get the current token.
* @param yyscanner The scanner object.
*/
char *ael_yyget_text (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yytext;
}
/** Set the user-defined data. This data is never touched by the scanner.
* @param user_defined The data to be associated with this scanner.
* @param yyscanner The scanner object.
*/
void ael_yyset_extra (YY_EXTRA_TYPE user_defined , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yyextra = user_defined ;
}
/** Set the current line number.
* @param line_number
* @param yyscanner The scanner object.
*/
void ael_yyset_lineno (int line_number , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
/* lineno is only valid if an input buffer exists. */
if (! YY_CURRENT_BUFFER )
yy_fatal_error( "ael_yyset_lineno called with no buffer" , yyscanner);
yylineno = line_number;
}
/** Set the current column.
* @param line_number
* @param yyscanner The scanner object.
*/
void ael_yyset_column (int column_no , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
/* column is only valid if an input buffer exists. */
if (! YY_CURRENT_BUFFER )
yy_fatal_error( "ael_yyset_column called with no buffer" , yyscanner);
yycolumn = column_no;
}
/** Set the input stream. This does not discard the current
* input buffer.
* @param in_str A readable stream.
* @param yyscanner The scanner object.
* @see ael_yy_switch_to_buffer
*/
void ael_yyset_in (FILE * in_str , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yyin = in_str ;
}
void ael_yyset_out (FILE * out_str , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yyout = out_str ;
}
int ael_yyget_debug (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yy_flex_debug;
}
void ael_yyset_debug (int bdebug , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yy_flex_debug = bdebug ;
}
/* Accessor methods for yylval and yylloc */
YYSTYPE * ael_yyget_lval (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yylval;
}
void ael_yyset_lval (YYSTYPE * yylval_param , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yylval = yylval_param;
}
YYLTYPE *ael_yyget_lloc (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
return yylloc;
}
void ael_yyset_lloc (YYLTYPE * yylloc_param , yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
yylloc = yylloc_param;
}
/* User-visible API */
/* ael_yylex_init is special because it creates the scanner itself, so it is
* the ONLY reentrant function that doesn't take the scanner as the last argument.
* That's why we explicitly handle the declaration, instead of using our macros.
*/
int ael_yylex_init(yyscan_t* ptr_yy_globals)
{
if (ptr_yy_globals == NULL){
errno = EINVAL;
return 1;
}
*ptr_yy_globals = (yyscan_t) ael_yyalloc ( sizeof( struct yyguts_t ), NULL );
if (*ptr_yy_globals == NULL){
errno = ENOMEM;
return 1;
}
/* By setting to 0xAA, we expose bugs in yy_init_globals. Leave at 0x00 for releases. */
memset(*ptr_yy_globals,0x00,sizeof(struct yyguts_t));
return yy_init_globals ( *ptr_yy_globals );
}
/* ael_yylex_init_extra has the same functionality as ael_yylex_init, but follows the
* convention of taking the scanner as the last argument. Note however, that
* this is a *pointer* to a scanner, as it will be allocated by this call (and
* is the reason, too, why this function also must handle its own declaration).
* The user defined value in the first argument will be available to ael_yyalloc in
* the yyextra field.
*/
int ael_yylex_init_extra(YY_EXTRA_TYPE yy_user_defined,yyscan_t* ptr_yy_globals )
{
struct yyguts_t dummy_yyguts;
ael_yyset_extra (yy_user_defined, &dummy_yyguts);
if (ptr_yy_globals == NULL){
errno = EINVAL;
return 1;
}
*ptr_yy_globals = (yyscan_t) ael_yyalloc ( sizeof( struct yyguts_t ), &dummy_yyguts );
if (*ptr_yy_globals == NULL){
errno = ENOMEM;
return 1;
}
/* By setting to 0xAA, we expose bugs in
yy_init_globals. Leave at 0x00 for releases. */
memset(*ptr_yy_globals,0x00,sizeof(struct yyguts_t));
ael_yyset_extra (yy_user_defined, *ptr_yy_globals);
return yy_init_globals ( *ptr_yy_globals );
}
static int yy_init_globals (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
/* Initialization is the same as for the non-reentrant scanner.
* This function is called from ael_yylex_destroy(), so don't allocate here.
*/
yyg->yy_buffer_stack = 0;
yyg->yy_buffer_stack_top = 0;
yyg->yy_buffer_stack_max = 0;
yyg->yy_c_buf_p = (char *) 0;
yyg->yy_init = 0;
yyg->yy_start = 0;
yyg->yy_start_stack_ptr = 0;
yyg->yy_start_stack_depth = 0;
yyg->yy_start_stack = NULL;
/* Defined in main.c */
#ifdef YY_STDINIT
yyin = stdin;
yyout = stdout;
#else
yyin = (FILE *) 0;
yyout = (FILE *) 0;
#endif
/* For future reference: Set errno on error, since we are called by
* ael_yylex_init()
*/
return 0;
}
/* ael_yylex_destroy is for both reentrant and non-reentrant scanners. */
int ael_yylex_destroy (yyscan_t yyscanner)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
/* Pop the buffer stack, destroying each element. */
while(YY_CURRENT_BUFFER){
ael_yy_delete_buffer(YY_CURRENT_BUFFER ,yyscanner );
YY_CURRENT_BUFFER_LVALUE = NULL;
ael_yypop_buffer_state(yyscanner);
}
/* Destroy the stack itself. */
ael_yyfree(yyg->yy_buffer_stack ,yyscanner);
yyg->yy_buffer_stack = NULL;
/* Destroy the start condition stack. */
ael_yyfree(yyg->yy_start_stack ,yyscanner );
yyg->yy_start_stack = NULL;
/* Reset the globals. This is important in a non-reentrant scanner so the next time
* ael_yylex() is called, initialization will occur. */
yy_init_globals( yyscanner);
/* Destroy the main struct (reentrant only). */
ael_yyfree ( yyscanner , yyscanner );
yyscanner = NULL;
return 0;
}
/*
* Internal utility routines.
*/
#ifndef yytext_ptr
static void yy_flex_strncpy (char* s1, yyconst char * s2, int n , yyscan_t yyscanner)
{
register int i;
for ( i = 0; i < n; ++i )
s1[i] = s2[i];
}
#endif
#ifdef YY_NEED_STRLEN
static int yy_flex_strlen (yyconst char * s , yyscan_t yyscanner)
{
register int n;
for ( n = 0; s[n]; ++n )
;
return n;
}
#endif
void *ael_yyalloc (yy_size_t size , yyscan_t yyscanner)
{
return (void *) malloc( size );
}
void *ael_yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner)
{
/* The cast to (char *) in the following accommodates both
* implementations that use char* generic pointers, and those
* that use void* generic pointers. It works with the latter
* because both ANSI C and C++ allow castless assignment from
* any pointer type to void*, and deal with argument conversions
* as though doing an assignment.
*/
return (void *) realloc( (char *) ptr, size );
}
#define YYTABLES_NAME "yytables"
#line 656 "ael.flex"
static void pbcpush(char x)
{
pbcstack[pbcpos++] = x;
}
void ael_yyfree(void *ptr, yyscan_t yyscanner)
{
if (ptr)
free( (char*) ptr );
}
static int pbcpop(char x)
{
if ( ( x == ')' && pbcstack[pbcpos-1] == '(' )
|| ( x == ']' && pbcstack[pbcpos-1] == '[' )
|| ( x == '}' && pbcstack[pbcpos-1] == '{' )) {
pbcpos--;
return 0;
}
return 1; /* error */
}
Merged revisions 141094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines (closes issue #13357) Reported by: pj Tested by: murf (closes issue #13416) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-04 23:31:41 +00:00
static void pbcpush2(char x)
{
pbcstack2[pbcpos2++] = x;
}
static int pbcpop2(char x)
{
if ( ( x == ')' && pbcstack2[pbcpos2-1] == '(' )
|| ( x == ']' && pbcstack2[pbcpos2-1] == '[' )
|| ( x == '}' && pbcstack2[pbcpos2-1] == '{' )) {
pbcpos2--;
return 0;
}
return 1; /* error */
}
static void pbcpush3(char x)
{
pbcstack3[pbcpos3++] = x;
}
static int pbcpop3(char x)
{
if ( ( x == ')' && pbcstack3[pbcpos3-1] == '(' )
|| ( x == ']' && pbcstack3[pbcpos3-1] == '[' )
|| ( x == '}' && pbcstack3[pbcpos3-1] == '{' )) {
pbcpos3--;
return 0;
}
return 1; /* error */
}
static int c_prevword(void)
{
char *c = prev_word;
if (c == NULL)
return 0;
while ( *c ) {
switch (*c) {
case '{':
case '[':
case '(':
pbcpush(*c);
break;
case '}':
case ']':
case ')':
if (pbcpop(*c))
return 1;
break;
}
c++;
}
return 0;
}
/*
* The following three functions, reset_*, are used in the bison
* code to switch context. As a consequence, we need to
* declare them global and add a prototype so that the
* compiler does not complain.
*
* NOTE: yyg is declared because it is used in the BEGIN macros,
* though that should be hidden as the macro changes
* depending on the flex options that we use - in particular,
* %reentrant changes the way the macro is declared;
* without %reentrant, BEGIN uses yystart instead of yyg
*/
void reset_parencount(yyscan_t yyscanner );
void reset_parencount(yyscan_t yyscanner )
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
parencount = 0;
pbcpos = 0;
pbcpush('('); /* push '(' so the last pcbpop (parencount= -1) will succeed */
c_prevword();
BEGIN(paren);
}
void reset_semicount(yyscan_t yyscanner );
void reset_semicount(yyscan_t yyscanner )
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
pbcpos = 0;
BEGIN(semic);
}
void reset_argcount(yyscan_t yyscanner );
void reset_argcount(yyscan_t yyscanner )
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
parencount = 0;
pbcpos = 0;
pbcpush('('); /* push '(' so the last pcbpop (parencount= -1) will succeed */
c_prevword();
BEGIN(argg);
}
/* used elsewhere, but some local vars */
struct pval *ael2_parse(char *filename, int *errors)
{
struct pval *pvalue;
struct parse_io *io;
char *buffer;
struct stat stats;
FILE *fin;
/* extern int ael_yydebug; */
io = calloc(sizeof(struct parse_io),1);
/* reset the global counters */
prev_word = 0;
my_lineno = 1;
include_stack_index=0;
my_col = 0;
/* ael_yydebug = 1; */
ael_yylex_init(&io->scanner);
fin = fopen(filename,"r");
if ( !fin ) {
ast_log(LOG_ERROR,"File %s could not be opened\n", filename);
*errors = 1;
return 0;
}
if (my_file)
free(my_file);
my_file = strdup(filename);
if (stat(filename, &stats)) {
ast_log(LOG_WARNING, "failed to populate stats from file '%s'\n", filename);
}
buffer = (char*)malloc(stats.st_size+2);
if (fread(buffer, 1, stats.st_size, fin) != stats.st_size) {
ast_log(LOG_ERROR, "fread() failed: %s\n", strerror(errno));
}
buffer[stats.st_size]=0;
fclose(fin);
ael_yy_scan_string (buffer ,io->scanner);
ael_yyset_lineno(1 , io->scanner);
/* ael_yyset_in (fin , io->scanner); OLD WAY */
ael_yyparse(io);
pvalue = io->pval;
*errors = io->syntax_error_count;
ael_yylex_destroy(io->scanner);
free(buffer);
free(io);
return pvalue;
}
static void setup_filestack(char *fnamebuf2, int fnamebuf_siz, glob_t *globbuf, int globpos, yyscan_t yyscanner, int create)
{
struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
int error, i;
FILE *in1;
char fnamebuf[2048];
if (globbuf && globbuf->gl_pathv && globbuf->gl_pathc > 0)
#if defined(STANDALONE) || defined(LOW_MEMORY) || defined(STANDALONE_AEL)
strncpy(fnamebuf, globbuf->gl_pathv[globpos], fnamebuf_siz);
#else
ast_copy_string(fnamebuf, globbuf->gl_pathv[globpos], fnamebuf_siz);
#endif
else {
ast_log(LOG_ERROR,"Include file name not present!\n");
return;
}
for (i=0; i<include_stack_index; i++) {
if ( !strcmp(fnamebuf,include_stack[i].fname )) {
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Nice Try!!! But %s has already been included (perhaps by another file), and would cause an infinite loop of file inclusions!!! Include directive ignored\n",
my_file, my_lineno, my_col, fnamebuf);
break;
}
}
error = 1;
if (i == include_stack_index)
error = 0; /* we can use this file */
if ( !error ) { /* valid file name */
/* relative vs. absolute */
if (fnamebuf[0] != '/')
snprintf(fnamebuf2, fnamebuf_siz, "%s/%s", ast_config_AST_CONFIG_DIR, fnamebuf);
else
#if defined(STANDALONE) || defined(LOW_MEMORY) || defined(STANDALONE_AEL)
strncpy(fnamebuf2, fnamebuf, fnamebuf_siz);
#else
ast_copy_string(fnamebuf2, fnamebuf, fnamebuf_siz);
#endif
in1 = fopen( fnamebuf2, "r" );
if ( ! in1 ) {
ast_log(LOG_ERROR,"File=%s, line=%d, column=%d: Couldn't find the include file: %s; ignoring the Include directive!\n", my_file, my_lineno, my_col, fnamebuf2);
} else {
char *buffer;
struct stat stats;
if (stat(fnamebuf2, &stats)) {
ast_log(LOG_WARNING, "Failed to populate stats from file '%s'\n", fnamebuf2);
}
buffer = (char*)malloc(stats.st_size+1);
if (fread(buffer, 1, stats.st_size, in1) != stats.st_size) {
ast_log(LOG_ERROR, "fread() failed: %s\n", strerror(errno));
}
buffer[stats.st_size] = 0;
ast_debug(1, " --Read in included file %s, %d chars\n",fnamebuf2, (int)stats.st_size);
fclose(in1);
if (include_stack[include_stack_index].fname) {
free(include_stack[include_stack_index].fname);
include_stack[include_stack_index].fname = 0;
}
include_stack[include_stack_index].fname = strdup(S_OR(my_file, "<none>"));
include_stack[include_stack_index].lineno = my_lineno;
include_stack[include_stack_index].colno = my_col+yyleng;
if (my_file)
free(my_file);
my_file = strdup(fnamebuf2);
if (create)
include_stack[include_stack_index].globbuf = *globbuf;
include_stack[include_stack_index].globbuf_pos = 0;
include_stack[include_stack_index].bufstate = YY_CURRENT_BUFFER;
if (create)
include_stack_index++;
ael_yy_switch_to_buffer(ael_yy_scan_string (buffer ,yyscanner),yyscanner);
free(buffer);
my_lineno = 1;
my_col = 1;
BEGIN(INITIAL);
}
}
}