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

[Mark Michelson]

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

(Updated June 17, 2014, 6:49 p.m.)


Status
------

This change has been marked as submitted.


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/20140617/65204aae/attachment.html>