[asterisk-bugs] [Asterisk 0012467]: Can't add 0 in front of function result within if() block of AEL
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Apr 21 09:49:08 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12467
======================================================================
Reported By: atis
Assigned To: murf
======================================================================
Project: Asterisk
Issue ID: 12467
Category: PBX/pbx_ael
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
Asterisk Version: 1.4.19
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 04-17-2008 08:23 CDT
Last Modified: 04-21-2008 09:49 CDT
======================================================================
Summary: Can't add 0 in front of function result within if()
block of AEL
Description:
I'm trying to construct syntax that will allow to use function result
directly in mathematical expression, and in case if function result is
empty (NULL), interpret that as 0. This works fine from .conf file or
realtime table:
Set(calls_missed_queue=$[0${DB(agent_globals/${target_num}/calls_missed_queue_${call_from_queue})}+1])
Here's the line from AEL that doesn't work:
if
(${GROUP_COUNT(${target_num}@agent_queue_b)}=1+0${DB(skip_group/${target_num}/agent_queue_b)});
Seems that there's no way how to use this within if() check directly, it
returns error at AEL compile time ("aelparse -d -n -w -q extensions.ael")
======================================================================
----------------------------------------------------------------------
murf - 04-21-08 09:49
----------------------------------------------------------------------
Why using this same expr in Set() gives no warnings: Because the pbx core,
when it comes time to execute an application, evaluates the arguments
before handing them to the application. It scans the arglist, and if it
finds a $[] or ${} expr, it evaluates and replaces it in the string with
its result. If the innards of the ${} or the $[] expr contains either ${}
or $[] exprs, they are recursively evaluated out of the input until none
are left. So, in this case, when an expr like
$[ 0${x} ] is evaluated, the pbx core sees first the outside $[] and
would like to pass it to the $[] parser, which is the ast_expr2 stuff, but
it scans the contents of the $[] and sees the ${x}. So, it will first
evaluate the ${x} and replace it with, say for example, 101. So, ast_expr
will always just see " 0101 ", which is just a single token, and that's
that. This is done at run time, just before the app call is executed.
In AEL, the Set() app call's arguments are simply passed thru without
inspection. That's why you get no complaints. I had earlier put code in
place to evaluate app call args, but I had to remove it because of loading
order, internal vs. external data availability, etc. if() expressions and
For(x;y;z) exprs are still tested, tho.
You see, the current app arg parser is pretty contextual and loose, and
users use it to do two things simultaneously: string formatting and
expression evaluation. This might seem like powerful features for users,
but in the end, it creates a lot of subtle headaches, and makes parsers
horribly complicated.
There is also the SPRINTF function to do explicit string formatting; So,
this is another alternative to building strings in the exact right format.
And, the $[] parser has already been upgraded to handle calling functions
inside exprs.
Issue History
Date Modified Username Field Change
======================================================================
04-21-08 09:49 murf Note Added: 0085749
======================================================================
More information about the asterisk-bugs
mailing list