-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3616/
-----------------------------------------------------------
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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
