Reversecharge

Hi!

Does Asterisk do lazy evaluation?

I modified, just for the sake of testing, extensions_additional.conf.

I didn't know how to echo what I wanted so I just assigned it to a variable that was already there:

I put this:

exten => 1235551212,n,Set(CHANNEL(musicclass)=default)
exten => 1235551212,n,Set(MOHCLASS=${REVERSAL_REJECT})
exten => 1235551212,n,Set(MOHCLASS=$["${REVERSAL_REJECT}"="TRUE"])
exten => 1235551212,n,Set(MOHCLASS=$["${REVERSAL_REJECT}"="TRUE" & "${CHANNEL(reversecharge)}"="1" ])
exten => 1235551212,n,GotoIf($["${_REVERSALREJECT}"="TRUE" & "${CHANNEL(reversecharge)}"="1" ]?macro-hangupcall)

I got this:

-- Executing [1235551212@from-trunk:7] Set("SIP/Voipms-00000000", "CHANNEL(musicclass)=default") in new stack
-- Executing [1235551212@from-trunk:8] Set("SIP/Voipms-00000000", "__MOHCLASS=") in new stack
-- Executing [1235551212@from-trunk:9] Set("SIP/Voipms-00000000", "__MOHCLASS=0") in new stack
[2015-09-07 19:54:28] WARNING[9380][C-00000000]: func_channel.c:596 func_channel_read: Unknown or unavailable item requested: 'reversecharge'
-- Executing [1235551212@from-trunk:10] Set("SIP/Voipms-00000000", "__MOHCLASS=0") in new stack
[2015-09-07 19:54:28] WARNING[9380][C-00000000]: func_channel.c:596 func_channel_read: Unknown or unavailable item requested: 'reversecharge'
-- Executing [1235551212@from-trunk:11] GotoIf("SIP/Voipms00000000", "0?macro-hangupcall") in new stack

(I got the reversecharge warning twice because I tried to assign it before using it in a goto hence the two warnings, once for the assignation, once for the goto...)

So it looks like for me:

_REVERSALREJECT gives me "" (an empty string)
"${_REVERSALREJECT}"="TRUE" gives me 0 (makes sense)

Ok so if Asterisk does lazy evaluation then why is "${CHANNEL(reversecharge)}"="1" evaluated?

This seems to suggest that Asterisk doesn't do lazy evaluation and evaluates everything

and that this test

$["${_REVERSALREJECT}"="TRUE" & "${CHANNEL(reversecharge)}"="1"

probably needs to be written with Goto's or maybe inline if's or something similar to avoid evaluating the missing reversecharge parameter (by jumping over the code that evaluate reversecharge...

I tried dicko's suggestion (there were some brackets missing in it though I believe) and it did not make a difference...

To me it looks like Asterisk doesn't do lazy evaluation and always evaluate everything even if the left side of the operator is false...

Thoughts?

Have a nice day!

Nick