[asterisk-bugs] [Asterisk 0011957]: It appears that a true branch is executed even when ExecIf() returns false

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11957 
====================================================================== 
Reported By:                blitzrage
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11957
Category:                   Applications/app_exec
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-08-2008 11:29 CST
Last Modified:              02-08-2008 12:26 CST
====================================================================== 
Summary:                    It appears that a true branch is executed even when
ExecIf() returns false
Description: 
I'm opening this for a bit of discussion as I believe the following
conditions could result in inefficiencies in the dialplan.

I have the following bit of dialplan code:

exten => h,n,Verbose(1,DIALSTATUS = ${DIALSTATUS})
exten => h,n,ExecIf($[${DIALSTATUS} =
ANSWER],Set,TIME_USED=${MATH(${ANSWEREDTIME}/60,f)})


But when I execute it in the dialplan, I end up with this:

    -- Executing [h at subPlaceCall:2] Verbose("SIP/4918847473-1565e170",
"1|DIALSTATUS = CANCEL") in new stack
 DIALSTATUS = CANCEL
[Feb  8 12:21:51] WARNING[19032]: func_math.c:169 math: '' is not a valid
number
    -- Executing [h at subPlaceCall:3] ExecIf("SIP/4918847473-1565e170",
"0|Set|TIME_USED=") in new stack


Which appears to be that the MATH() function is being executed before the
condition is checked. That seems backwards to me in that the condition
should be checked before any action is taken on the arguments provided.

I've seen the same behaviour with the IF() function as well:

exten => h,n,Exec(${IF(${DIALSTATUS} =
ANSWER]?Set(TIME_USED=${MATH(${ANSWEREDTIME}/60,f)}):NoOp())})

Same behaviour happens where MATH() returns an error because
${ANSWEREDTIME} is not populated (and it shouldn't be -- the call was not
answered).
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 02-08-08 12:26  
---------------------------------------------------------------------- 
I was going to close this as I think the behavior is intentional. I believe
the idea is that it is more efficient to substitute all the variables and
functions prior to actually running the application. If you set a value for
TIME_USED prior to the ExecIf call and check its value after, you'll see
that the true branch was not actually executed (i.e. TIME_USED will be the
same as what you set it to prior to the ExecIf call), just the variables
and functions were substituted.

Now the reason I said I was going to close this was because I thought that
since the actual application in the true branch of ExecIf did not get
executed it wouldn't be a huge deal. The problem is that this can cause
some very unexpected results if for instance you were to use the SET
function in the true branch. I suspect that it would get evaluated and set
the variable to the new value even if the true application were not
executed. In your example, had you done this:

exten => h,n,Verbose(1,DIALSTATUS = ${DIALSTATUS})
exten => h,n,ExecIf($[${DIALSTATUS} =
ANSWER],Noop,SET(TIME_USED=${MATH(${ANSWEREDTIME}/60,f)}))

I suspect that TIME_USED would be set to a new value even if the condition
were not true. This therefore needs to be looked at more carefully. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-08-08 12:26  putnopvut      Note Added: 0081929                          
======================================================================