| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@141094 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: korihor
Wow, this one was a challenge!
I regrouped and ran a new strategy for
setting the ~~MACRO~~ value; I set it once
per extension, up near the top. It is only
set if there is a switch in the extension.
So, I had to put in a chunk of code to detect
a switch in the pval tree.
I moved the code to insert the set of ~~exten~~
up to the beginning of the gen_prios routine,
instead of down in the switch code.
I learned that I have to push the detection
of the switches down into the code, so everywhere
I create a new exten in gen_prios, I make sure
to pass onto it the values of the mother_exten
first, and the exten next.
I had to add a couple fields to the exten
struct to accomplish this, in the ael_structs.h
file. The checked field makes it so we don't
repeat the switch search if it's been done.
I also updated the regressions.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136726 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
from callfiles and AMI.
(closes issue #9531)
Reported by: Geisj
Patches:
20080715__bug9531__1.4.diff.txt uploaded by Corydon76 (license 14)
20080715__bug9531__1.6.0.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@134976 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: pj
(closes issue #13051)
Reported by: pj
This patch substitutes commas in the expr
supplied to the if () statement, as in
if ( expr ) ...
This solves both the bugs above, and makes
the source symmetric with switch statements,
which were earlier reported to need this sort
of treatment.
I tested this using the examples, both for
the compiler and at run time. Looks good.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@134652 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
compiled with LOW_MEMORY.
(closes issue #13154)
Reported by: edantie
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@134595 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: murf
The problem was that, esoteric as it is, because the hangerupper
context immediately preceded the std-priv-extent macro, that
the checking code accidentally would fall from traversing hangerupper
into the std-priv-exten macro, where it would hit the hangerupper
in the 'includes', and proceed into an infinite recursion.
A small fix to traverse into the statements of the context instead
of the context solves this issue.
I also added some commented out printfs for debug, which were pretty
handy in the face of a dorky gdb.
This was a problem around since the package was first written;
but evidently pretty rare in turning up in the field.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131242 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This commit fixes the use of RAND in the ael random function.
(closes issue #13061)
Reported by: danpwi
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130373 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@128029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and b) completes contexts correctly when the extension is ambiguous.
(closes issue #12980)
Reported by: licedey
Patches:
20080703__bug12980.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@127973 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@126395 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the last one will take precedence.
(closes issue #12673)
Reported by: phber
Patches:
20080519__bug12673.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@123710 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
should continue working. Release announcement to follow.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122314 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
some formatting, and make the success message a little bit more clear.
(closes AST-52)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120371 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12716)
Reported by: chappell
Patches:
dialplan_reload_2.diff uploaded by chappell (license 8)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120282 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
cannot perform any translation on the extension number before searching for it
in the target context.
(closes issue #12473)
Reported by: chappell
Patches:
pbx_loopback.c.diff uploaded by chappell (license 8)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120226 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
this for the changes I made to preserve ${EXTEN}
in switches, which affected several tests because
it adds extra priorities, and at least one needed to be updated
because of the removal of the empty extension warning
message.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119966 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
which is a message from Philipp Kempgen, requesting that the WARNING
that an extension is empty be reduced to a NOTICE or less, as empty
extensions are syntactically possible, and no big deal.
With which I agree, and have removed that WARNING message entirely.
I think it is not necessary to see this message. It didn't
state that a NoOp() was inserted automatically on your behalf,
and really, as users, who cares? Why freak out dialplan writers
with unnecessary warnings? The details of the machinations a compiler goes
thru to produce working assembly code is of little interest
to most programmers-- we will follow the unix principal of
doing our work silently.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119929 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@117523 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Related to issue #12702)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@117519 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
being sent to remote consoles.
2) Fix pbx_gtkconsole to filter out the verbose marker.
(related to issue #12702)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@117507 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: pj
Tested by: murf
These changes will set a channel variable ~~EXTEN~~ just before generating code
for a switch, with the value of ${EXTEN}. The exten is marked as having a switch,
and ever after that, till the end of the exten, we substitute any ${EXTEN}
with ${~~EXTEN~~} instead in application arguments; (and the ${EXTEN: also).
The reason for this, is that because switches are coded using
separate extensions to provide pattern matching, and
jumping to/from these switch extensions messes up the ${EXTEN} value,
which blows the minds of users.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111341 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: atis
Many thanks to atis for spotting this problem and reporting it.
The fix was to straighten out how items are placed on and removed
from the file stack. Regressions as well as the provided test case
helped to straighten out all code paths. valgrind was used to make
sure all memory allocated was freed.
Sorry for not solving this earlier. I got distracted.
Added the ntest23 regression test, which is mainly a copy of ntest22,
but with a few juicy errors thrown in, to replicate the kind of
error that atis spotted.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109309 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- the output of flex includes a static function called 'input' that is not used, so for the moment we'll stop having the compiler tell us about unused variables in the flex source files (a better fix would be to improve our flex post-processing to remove the unused function)
- main/stdtime/localtime.c makes assumptions about signed integer overflow, and gcc-4.3's improved optimizer tries to take advantage of handling potential overflow conditions at compile time; for now, suppress these optimizations until we can fiure out if the code needs improvement
- main/udptl.c has some references to uninitialized variables; in one case there was no bug, but in the other it was certainly possibly for unexpected behavior to occur
- main/editline/readline.c had an unused variable
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107352 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
CFLAGS and include directory paths
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@102627 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption. Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue #11386)
Reported by: flujan
Patches:
20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100465 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11646)
Reported by: caio1982
Patches:
dundi_osx_eid6.diff.txt uploaded by caio1982 (license 22)
dundi_osx_eid6-1.4.diff uploaded by caio1982 (license 22)
Tested by: caio1982, mvanbaak
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98390 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
overrode the normally generate yyfree func with our own version that checks the pointer for non-null before passing to free(). Also takes care of a little problem with 2.5.33 and the use of the __STDC_VERSION__ macro.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97889 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97753 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
complained.
(closes issue #11706, reported by caio1982)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97734 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97645 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(related to issue #11706)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97640 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
or wrlock
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@96024 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@96022 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@93183 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@93180 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
enabled.
(closes issue #11347)
Reported by: ys
Patches:
pbx.pbx_config.c.diff uploaded by ys (license 281)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89592 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
leakage I've already fixed, but it doesn't hurt to double check. I found and fixed leaks in res_jabber, cdr_tds, pbx_ael. Nothing major, tho.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89088 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
where the semicolon is not escaped. Fixed this; User also wanted comments to be preserved across dialplan save, but this is impossible at this point in time, because comments are not stored in the dialplan. They are 'compiled' out of extensions.conf. The only way to preserve those comments is to use the config file reader/writer that the GUI uses to allow online user edits. extensions.conf is first and foremost, a config file, and is read in by the normal config-file reading routines. Then, it is processed into a dialplan (context/exten structs).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87849 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
included contexts that have no match in the AEL, might be OK, as AEL cannot check in the extensions.conf or the in-memory contexts, as they may not be there at the time of the check.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87775 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87168 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86936 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11041)
Reported by: jsmith
Patches:
asterisk-dundicomplete.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86661 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
that it is null terminated.
(issue #10977)
Reported by: dimas
Patches:
pbxdundi.patch uploaded by dimas (license 88)
- small mods by me
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85556 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
user exists.
(closes issue #10971)
Reported by: dimas
Patches:
pbxconfig.patch uploaded by dimas (license 88)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85540 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #10958)
Reported by: dimas
Patches:
realtime.patch uploaded by dimas (license 88)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85515 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
execute correctly, because the commas in the function args are not converted to vertbars before the func is called. I modified just the switch code to convert the commas to vertbars if there, but if more of these sort of probs are found, I may have to resort to something a little more fundamental. We'll see, I guess.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84544 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
hangup; since switch is implemented with extensions, and the default case is implemented with a '.', and the '.' matches 1 or more remaining characters, the case where 0 characters exist isn't matched, and the extension isn't matched, and the goto fails, and a hangup occurs. Now, when a default case is generated, it also generates a single fixed extension that will match a null input. That extension just does a goto to the default extension for that switch. I played with an alternate solution, where I just tack an extra char onto all the patterns and the goto, but not the default case's pattern. Then even a null input will still have at least one char in it. But it made me nervous, having that extra char in , even if that's a pretty secret and low-level issue.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84511 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84273 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
really nothing there, and making sure we don't try to do checking on a null tree.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84239 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
regressions.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84135 f38db490-d61c-443f-a65b-d21fe96a405b
|
