Merged revisions 177225 via svnmerge from
authorSteve Murphy <murf@digium.com>
Wed, 18 Feb 2009 23:50:57 +0000 (23:50 +0000)
committerSteve Murphy <murf@digium.com>
Wed, 18 Feb 2009 23:50:57 +0000 (23:50 +0000)
commit6c2a537c5fb2b973e4a94fa551dbc4a6b6594cda
tree060e1eb66ae6e314ec1ccb284581ebe7abe9e0aa
parentb2d959c7fa707d4e107126c408df3f18f3fa0d74
Merged revisions 177225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines

  This patch fixes a regression of sorts that was introduced in
  rev 24425.

  It basically fixes AST-190/ABE-1782.

  What was wrong: the user has 6000 extensions in one context; and
  then 6000 contexts, one per extension. The parser could only handle
  about 4893 of the 6000 extens in the single context.

  This was due to the regression I mentioned. To get rid of
  shift/reduce conflicts, Luigi set up right-recursive lists
  for globals, context elements, switch lists, and statements.
  Right recursive lists got rid of the warnings, but instead, they
  use up a tremendous amount of stack space when the lists are long.

  I saw this a few years back, and resolved not to fix it until
  someone complained. That day has arrived!

  After the changes were made, I ran the regression test suite,
  and there were no problems.

  I took the test case the user provided, and added 100,000
  extensions to the single context, that already had 6,000 extens
  in it. (I'll see your 6, and raise you 100!) It takes a few minutes
  to read it all in, check it and generate code for it, but no
  problems.

  So, I think I can say that fundamentally, there are no longer
  any limits on the number of items you can place in contexts,
  statement blocks, switches, or globals, beyond your virt mem
  constraints.
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res/ael/ael.tab.c
res/ael/ael.y