----------------------------------------------------------- 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 > >
-- _____________________________________________________________________ -- 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
