[asterisk-dev] [Code Review] 3616: Allow PUSH() and UNSHIFT() functions to use inheritable channel variables.

Corey Farrell reviewboard at asterisk.org
Fri Jun 13 14:33:55 CDT 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3616/#review12148
-----------------------------------------------------------

Ship it!


Please commit against 1.8+.  r3619 passes against 1.8 with this change, fails without it.

- Corey Farrell


On June 12, 2014, 6:53 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3616/
> -----------------------------------------------------------
> 
> (Updated June 12, 2014, 6:53 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Asterisk has an interesting asymmetry when it comes to reading and writing channel variables. When setting a channel variable, you can do something like:
> 
> exten => foo,n,Set(__BAR=hello)
> 
> But when you read from that variable, you will not get the same result by doing
> 
> exten => foo,n,NoOp(${__BAR})
> 
> That will evaluate to an empty string. Instead, you must reference the variable without the leading underscores:
> 
> exten => foo,n,NoOp(${BAR})
> 
> That will evaluate to "hello"
> 
> This asymmetry mostly does not cause problems, except in rare cases, like the PUSH and UNSHIFT dialplan functions. Take the following sample dialplan:
> 
> exten => foo,1,Set(PUSH(__BAR)=hello)
> exten => foo,2,NoOp(${BAR})
> exten => foo,3,Set(PUSH(__BAR)=world)
> exten => foo,4,NoOp(${BAR})
> 
> In this case, you want to have an inheritable array and be able to push values onto the back of it. The above construct, though, does not do what is expected. At priority 2, BAR evaluates to "hello" as you might expect. However, at priority 4, BAR evaluates to "world" instead of the expected "hello,world".
> 
> The problem here is that the PUSH and UNSHIFT dialplan functions work in both a read and write context for a channel variable. They first read the variable in order to get the previously set value, and they then write the new value to the beginning or end of the array. Because of the earlier example I gave where trying to evaluate ${__BAR} did not give the previously-set value, attempting to PUSH or UNSHIFT with a __ variable did not have the expected result.
> 
> This patch aims to fix the problem by retrieving the variable without the leading underscores but then setting the new value with leading underscores.
> 
> There are other dialplan functions in func_strings that take variable names as parameters (FIELDQTY, FIELDNUM, LISTFILTER, REPLACE, STRREPLACE, EVAL, SHIFT, and POP), but these all are intended to evaluate or modify pre-existing channel variables rather than to (possibly) create variables. For that reason, none of the other dialplan functions in func_strings.c are touched by this patch.
> 
> 
> Diffs
> -----
> 
>   /branches/12/funcs/func_strings.c 416051 
> 
> Diff: https://reviewboard.asterisk.org/r/3616/diff/
> 
> 
> Testing
> -------
> 
> The sample dialplan in the description evaluates to "hello,world" at priority 4 with this patch applied.
> 
> I am working on an official testsuite test, but I am currently having difficulties with the testsuite.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140613/1d21c64d/attachment.html>


More information about the asterisk-dev mailing list