[Home]

Summary:ASTERISK-13716: [patch] Add support in AEL for macro return values and direct assignment of them to variables and functions.
Reporter:Bradley Watkins (marquis)Labels:patch
Date Opened:2009-03-09 06:03:11Date Closed:2018-01-02 08:49:52.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-18593 AEL for loops use Macro app and pipe delimiter
Environment:Attachments:( 0) 20100121__issue14629.diff.txt
( 1) macro_assignment_20100126.patch
( 2) macro_assignment.patch
Description:This patch adds macro return value and simple assignment support to AEL.

This is the bug report for review request 114 as per Russell Bryant.
http://reviewboard.digium.com/r/114/

****** ADDITIONAL INFORMATION ******

Attempting to use the already-existing functionality of the Return application for returning values from a GoSub would result in warnings from AEL and the insertion of one or more superfluous Return() calls.

With this patch, AEL allows Return(${VAR}) constructs and additionally simple assignment from a macro call.
Comments:By: Leif Madsen (lmadsen) 2009-06-10 12:13:12

Been a while since this issue was updated. Just thought I'd poke it and see where we are on the reviewboard?
By: Bradley Watkins (marquis) 2009-06-10 15:56:43

I have not heard anything about it myself.  I'm just waiting for some feedback.
By: Leif Madsen (lmadsen) 2009-06-12 08:09:15

OK, we'll just have to be patient then I suppose :)  I'm going to assign murf to this issue, but not 100% sure he'll have time to look at it. But we'll give it a shot! :)
By: Bradley Watkins (marquis) 2009-11-23 16:54:45.000-0600

dbrooks:  I noticed you tried to contact me via IRC, but I wasn't around at the time.

To answer your question regarding the test cases in pbx/ael/ael-tests, it appears that even a vanilla checkout of trunk fails a whole bunch of them.  I know there was at least one change I can see based on the new output (Using LOCAL for ${~~EXTEN~~} assignment in a macro it looks like).

Basically, whomever made that change forgot (or didn't know) to update the reference output used for the tests.

Now that I've done that locally, I'll apply my patch and make sure all the tests still pass and update the patch if necessary.
By: Bradley Watkins (marquis) 2009-11-23 17:23:01.000-0600

After applying my patch, regenerating the lexer and parser, and recompiling, all tests pass.
By: Chris Walton (crjw) 2010-01-21 08:38:48.000-0600

I tried to use this patch for the first time yesterday.
I was trying it with with the latest trunk code (version:241714M).

When I attempt to pass an argument to "return", the parser reports a syntax error.

e.g.:
With this macro (as copied from the CHANGES file):
   macro returnmacro() {
       MYVAR=10;
       return ${MYVAR};
   }
I get the error:
ERROR[10825]: ael.y:840 ael_yyerror: ==== File: /apps/asterisk/etc/extensions.ael, Line 71, Cols: 16-24: Error: syntax error, unexpected word, expecting ';'

I am running this on Solaris SXCE 129.  But I doubt the OS should make much of a difference.

In the last posting by Marquis' on nov 23/2009, there is mention of regenerating the lexer and parser.  Is this something that everybody applying the patch is supposed to do? And if so, how is this done?
In my testing I simply downloaded the latest trunk into an brand new directory, applied the patch, compiled, and installed.
By: Tilghman Lesher (tilghman) 2010-01-21 09:12:33.000-0600

You additionally need the Makefile rules in the diff I just uploaded to ensure that the files are correctly rebuilt.
By: Chris Walton (crjw) 2010-01-21 21:27:07.000-0600

Okay, I applied both patches:
"macro_assignment.patch"
AND
"20100121__issue14629.diff.txt"

Things are better but there are still problems.

I no longer get a syntax error when I pass an argument to "return".
e.g. This parses without error:
macro returnmacro() {
  MYVAR=10;
  return ${MYVAR};
}

But direct assignment of the variable gives an error.
e.g.
 401 =>{
   FOO=&returnmacro();
 }
generates the following error:
ast_expr2.fl:468 ast_yyerror: ast_yyerror(): file /apps/asterisk/etc/extensions.ael, line 209, columns 16-36, variable declaration expr '&returnmacro()': syntax error: syntax error, unexpected '&', expecting $end; Input:
&returnmacro()
^

I can work around the problem by doing this:
401 =>{
 &returnmacro();
 FOO=${GOSUB_RETVAL};
}
... but this work around seems a little kludgey.
By: Chris Walton (crjw) 2010-01-22 00:54:07.000-0600

It seems that the parser always aways converts
 "return ${xx}"  to "Return($[${xx}])"

I am not sure why it must insert the extra dollar sign and square brackets.
If variable ${x} happens to contain an embeded comma, a runtime warning is generated and only the portion of the string before the comma is returned.
e.g.
     Set(LOCAL(xx)=240,m);  // A five character string with embeded comma.
     NoOp(${xx});           // The string "240,m" is displayed.  Good so far.
     return ${xx};          // Nasty stuff starts to happen!
Here is the Warning:
WARNING[27604]: ast_expr2.fl:468 ast_yyerror: ast_yyerror():  syntax error: syntax error, unexpected ',', expecting $end; Input:
240,m
  ^
Only the value 240 is returned.  the comma and the letter m are stripped out.


If I use "Return(${xx})" instead of "return ${xx}" then everything works, but the parser generates standard warnings about using GoSub in AEL.
By: Bradley Watkins (marquis) 2010-01-22 09:06:24.000-0600

The code is currently written exactly as a regular assignment is in AEL, which is to wrap it as an express (i.e., the observed $[] behavior).

The idea was to let expressions with math, etc., function directly in the return line.  But that obviously has other problems I hadn't thought of.

Perhaps the right thing to do here is to NOT wrap it as an expression, but document that you can't use expressions directly.  You'll have to assign the expression's result to a variable and then return the variable.

So, assuming you wanted to perform math, this wouldn't work:
return 8-2;  <--- return value would be the literal string, not 6

But this would:
MATHRESULT=8-2;
return ${MATHRESULT};

The other option, though I haven't evaluated how difficult it would be to code, is to make AEL support a return value in quotes as a string literal.
By: Tilghman Lesher (tilghman) 2010-01-22 09:43:56.000-0600

I think it's sufficiently merely to do

return "${xx}", since that evaluates to:

Return($["${xx}"]), which should validate fine.
By: Bradley Watkins (marquis) 2010-01-22 10:37:44.000-0600

Yeah, that's exactly what should be done.  I should also read/remember my own code, because it's exactly how this will behave as written.
By: Chris Walton (crjw) 2010-01-22 10:42:18.000-0600

I tried doing:   return "${xx}"
But that returns a string which starts and ends with a quote.
i.e. the quotes become part of the string.

I think it would be safest let the parser map 'return ${xx}' to 'Return(${xx})'.
If somebody wants to do math, they can do it prior to the 'return' statement as shown in the example posted by Marquis' this morning.

Please note: this issue is not related to the issue I posted at 2010-01-21 21:27.
i.e. there are two unrelated problems which need to be dealt with separately.
1) Direct assignment of macro to variable gives a syntax error.
2) Arg to 'return' is subject to math evaluation when it should not be.
By: Tilghman Lesher (tilghman) 2010-01-22 11:31:54.000-0600

I agree with fixing 1, but I think 2 is best left alone for now.
By: Chris Walton (crjw) 2010-01-22 12:15:14.000-0600

Sorry to disagree.  But I think "both" issues should be addressed.

My earlier posts mentions problems with commas.
Hyphens create problems too!

#################################
// this macro adds hyphens to a 10 digit phone number
macro hyphens(number) {
 Set(LOCAL(xx)=${number:0:3}-${number:3:3}-${number:6:4});
 NoOp(${xx});
 return ${xx};
}

305 =>{
 &hyphens(8005551212);
   NoOp(${GOSUB_RETVAL});
   HangUp;
 }

When 305 is dialed, the NoOp inside the macro shows the number with the hypens properly embeded, but and the NoOp in the 305 extension shows the result of
an unwanted mathematical calculation.
Executing [305@home1:1] Gosub("SIP/x300-00000019", "hyphens,s,1(8005551212)")
Executing [s@hyphens:1] MSet("SIP/x300-00000019", "LOCAL(number)=8005551212")
Executing [s@hyphens:2] Set("SIP/x300-00000019", "LOCAL(xx)=800-555-1212")
Executing [s@hyphens:3] NoOp("SIP/x300-00000019", "800-555-1212")
Executing [s@hyphens:4] Return("SIP/x300-00000019", "-967")
Executing [305@home1:2] NoOp("SIP/x300-00000019", "-967")

If I use 'return "${xx}"'   instead of 'return ${xx}' the extra quotes become part of the string which is completely undesirable.
Executing [305@home1:1] Gosub("SIP/x300-0000001a", "hyphens,s,1(8005551212)")
Executing [s@hyphens:1] MSet("SIP/x300-0000001a", "LOCAL(number)=8005551212")
Executing [s@hyphens:2] Set("SIP/x300-0000001a", "LOCAL(xx)=800-555-1212")
Executing [s@hyphens:3] NoOp("SIP/x300-0000001a", "800-555-1212")
Executing [s@hyphens:4] Return("SIP/x300-0000001a", ""800-555-1212"")
Executing [305@home1:2] NoOp("SIP/x300-0000001a", ""800-555-1212"")

If I use 'Return({$xx})'  then the macro returns the proper string.
But I get a warning:
WARNING[27604]: ael/pval.c:2557 check_pval_item: Warning: file /apps/asterisk/etc/extensions.ael, line 696-696: application call to Return affects flow of control, and needs to be re-written using AEL if, while, goto, etc. keywords instead!
By: Tilghman Lesher (tilghman) 2010-01-22 15:11:04.000-0600

Let's try this construct for the quoting issue:

Set(foo=${IF($[${GOSUB_RETVAL:0:1}${GOSUB_RETVAL:-1}=""]?${CUT(GOSUB_RETVAL,\",2)}:${GOSUB_RETVAL})})

That makes it such that if you quote the output for the return value, because you have a literal string, you're good, but if you have an expression, that works, too.
By: Bradley Watkins (marquis) 2010-01-22 15:22:55.000-0600

If you're still having issues with direct assignment to a variable from a macro, then your flex and bison stuff isn't working properly.

Also, I think you're misinterpreting the console output you've pasted.  If you get the assignment to work properly, then the resulting value of the variable will not have the quotes in it even though the call to Return and the NoOp on GOTSUB_RETVAL show them.  Here's the output on my system using your macro (name differently, but with the same contents:

   -- Executing [s@test-assignment:1] Gosub("SIP/test-00000002", "test-assignment-macro,s,1(12345678)") in new stack
   -- Executing [s@test-assignment-macro:1] MSet("SIP/test-00000002", "LOCAL(number)=12345678") in new stack
   -- Executing [s@test-assignment-macro:2] Set("SIP/test-00000002", "LOCAL(xx)=123-456-78") in new stack
   -- Executing [s@test-assignment-macro:3] NoOp("SIP/test-00000002", "123-456-78") in new stack
   -- Executing [s@test-assignment-macro:4] Return("SIP/test-00000002", ""123-456-78"") in new stack
   -- Executing [s@test-assignment:2] MSet("SIP/test-00000002", "assignment="123-456-78"") in new stack
   -- Executing [s@test-assignment:3] NoOp("SIP/test-00000002", "123-456-78") in new stack
By: Digium Subversion (svnbot) 2010-01-22 15:44:19.000-0600

Repository: asterisk
Revision: 242423

U   branches/1.4/pbx/Makefile

------------------------------------------------------------------------
r242423 | tilghman | 2010-01-22 15:44:19 -0600 (Fri, 22 Jan 2010) | 7 lines

Rebuild from flex, bison sources when necessary.

(issue ASTERISK-13716)
Reported by: Marquis
Patches:
      20100121__issue14629.diff.txt uploaded by tilghman (license 14)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=242423
By: Digium Subversion (svnbot) 2010-01-22 15:45:19.000-0600

Repository: asterisk
Revision: 242424

_U  trunk/
U   trunk/res/Makefile

------------------------------------------------------------------------
r242424 | tilghman | 2010-01-22 15:45:19 -0600 (Fri, 22 Jan 2010) | 14 lines

Merged revisions 242423 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r242423 | tilghman | 2010-01-22 15:44:18 -0600 (Fri, 22 Jan 2010) | 7 lines
 
 Rebuild from flex, bison sources when necessary.
 
 (issue ASTERISK-13716)
  Reported by: Marquis
  Patches:
        20100121__issue14629.diff.txt uploaded by tilghman (license 14)
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=242424
By: Digium Subversion (svnbot) 2010-01-22 15:46:28.000-0600

Repository: asterisk
Revision: 242425

_U  branches/1.6.0/
U   branches/1.6.0/res/Makefile

------------------------------------------------------------------------
r242425 | tilghman | 2010-01-22 15:46:27 -0600 (Fri, 22 Jan 2010) | 21 lines

Merged revisions 242424 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r242424 | tilghman | 2010-01-22 15:45:18 -0600 (Fri, 22 Jan 2010) | 14 lines
 
 Merged revisions 242423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r242423 | tilghman | 2010-01-22 15:44:18 -0600 (Fri, 22 Jan 2010) | 7 lines
   
   Rebuild from flex, bison sources when necessary.
   
   (issue ASTERISK-13716)
    Reported by: Marquis
    Patches:
          20100121__issue14629.diff.txt uploaded by tilghman (license 14)
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=242425
By: Digium Subversion (svnbot) 2010-01-22 15:46:37.000-0600

Repository: asterisk
Revision: 242426

_U  branches/1.6.1/
U   branches/1.6.1/res/Makefile

------------------------------------------------------------------------
r242426 | tilghman | 2010-01-22 15:46:37 -0600 (Fri, 22 Jan 2010) | 21 lines

Merged revisions 242424 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r242424 | tilghman | 2010-01-22 15:45:18 -0600 (Fri, 22 Jan 2010) | 14 lines
 
 Merged revisions 242423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r242423 | tilghman | 2010-01-22 15:44:18 -0600 (Fri, 22 Jan 2010) | 7 lines
   
   Rebuild from flex, bison sources when necessary.
   
   (issue ASTERISK-13716)
    Reported by: Marquis
    Patches:
          20100121__issue14629.diff.txt uploaded by tilghman (license 14)
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=242426
By: Digium Subversion (svnbot) 2010-01-22 15:46:45.000-0600

Repository: asterisk
Revision: 242427

_U  branches/1.6.2/
U   branches/1.6.2/res/Makefile

------------------------------------------------------------------------
r242427 | tilghman | 2010-01-22 15:46:45 -0600 (Fri, 22 Jan 2010) | 21 lines

Merged revisions 242424 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r242424 | tilghman | 2010-01-22 15:45:18 -0600 (Fri, 22 Jan 2010) | 14 lines
 
 Merged revisions 242423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r242423 | tilghman | 2010-01-22 15:44:18 -0600 (Fri, 22 Jan 2010) | 7 lines
   
   Rebuild from flex, bison sources when necessary.
   
   (issue ASTERISK-13716)
    Reported by: Marquis
    Patches:
          20100121__issue14629.diff.txt uploaded by tilghman (license 14)
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=242427
By: Tilghman Lesher (tilghman) 2010-01-22 16:02:33.000-0600

I concur.  This is not quite ready yet.

[Jan 22 15:59:06] NOTICE[8639]: pbx_ael.c:122 pbx_load_module: Starting AEL load process.
[Jan 22 15:59:06] ERROR[8639]: ael.y:836 ael_yyerror: ==== File: /etc/asterisk/extensions.ael, Line 326, Cols: 21-25: Error: syntax error, unexpected word, expecting ';'
[Jan 22 15:59:06] ERROR[8639]: ael.y:836 ael_yyerror: ==== File: /etc/asterisk/extensions.ael, Line 343, Cols: 8-8: Error: syntax error, unexpected '}'
[Jan 22 15:59:06] NOTICE[8639]: pbx_ael.c:135 pbx_load_module: AEL load process: parsed config file name '/etc/asterisk/extensions.ael'.
[Jan 22 15:59:06] WARNING[8639]: ael/pval.c:707 check_macro_returns: Warning: file /etc/asterisk/extensions.ael, line 324-342: The macro ael_sample does not end with a return; I will insert one.
[Jan 22 15:59:06] WARNING[8639]: ael/pval.c:859 check_includes: Warning: file /etc/asterisk/extensions.ael, line 392-394: The included context 'ael-demo' cannot be found.
(You may ignore this warning if 'ael-demo' exists in extensions.conf, or is created by another module. I cannot check for those.)
[Jan 22 15:59:06] ERROR[8639]: pbx_ael.c:151 pbx_load_module: Sorry, but 2 syntax errors and 0 semantic errors were detected. It doesn't make sense to compile.

with:

macro ael_sample() {
   NoOp;
   return "foo bar";
};

context ael-demo {
   s => {
       Wait(1);
       Answer();
       Set(foo=&ael_sample());
       Set(TIMEOUT(digit)=5);
       Set(TIMEOUT(response)=10);
restart:
       Background(demo-congrats);
instructions:
       for (x=0; ${x} < 3; x=${x} + 1) {
           Background(demo-instruct);
           WaitExten();
       };
   };
...
By: Bradley Watkins (marquis) 2010-01-22 16:11:35.000-0600

You can't use macro assignment inside of a Set(). Direct assignment is the only way.

AEL puts the contents of a Set() verbatim into the dialplan with no conversions as an ability to work around its own default of wrapping assignments in an expression ($[]).
By: Chris Walton (crjw) 2010-01-22 17:06:15.000-0600

I tried using:
Set(foo=${IF($[${GOSUB_RETVAL:0:1}${GOSUB_RETVAL:-1}=""]?${CUT(GOSUB_RETVAL,\",2)}:${GOSUB_RETVAL})})
This works.  But... it is not at all pretty.

The purpose of a macro is presumably to reduce repetitive code and make the dialplan more legible.
If I were to reference a partiular macro from 100 different extensions then I would have to insert this kludge code 100 times.
If we need to repeat the same lines of code each time we call a macro, then we are defeating the purpose of the macro.

I think the macro should be flexible enough to directly return any type of data without making assumptions about the data.
If somebody wants to do mathematics inside the macro, that is fine; it could be done with one or two lines inside the macro.
If a macro ends up being twenty lines instead of eighteen does it matter?
By: Tilghman Lesher (tilghman) 2010-01-22 17:14:31.000-0600

crjw:  The purpose of that code was to use it within the AEL compiler, not to force the end user to use it.  The AEL compiler does a lot of stuff that is ugly behind the scenes, in order to make the AEL language itself easy to use.


By: Tilghman Lesher (tilghman) 2010-01-22 17:15:36.000-0600

Setting back to Acknowledged while Marquis fixes an issue in returning literal strings.
By: Bradley Watkins (marquis) 2010-01-26 18:46:14.000-0600

OK, have a go with this new patch.

The way it now works is that we just use Return(), parse it like an application call (using the existing code to just glob everything between parens), but don't warn about its use as it would have before.

Also, modified the additions to CHANGES to both be in the proper place and to use the new syntax.
By: Chris Walton (crjw) 2010-01-26 22:36:47.000-0600

OK.
I applied macro_assignment_20100126.patch to latest trunk (version 243391M).

Now, referencing the two issues discussed on Jan 22:

#1: "Direct assignment of macro to variable gives a syntax error"
This is still broken for me.  It may be a flex/bison issue (as suggested by Marquis) but I don't know enough about flex or bison to troubleshoot this.
#########################################################################
 WARNING[9417]:
  ast_expr2.fl:468 ast_yyerror: ast_yyerror(): file /apps/asterisk/etc/extensions.ael, line 403, columns 8-31, variable declaration expr '&returnmacro(1-2)': syntax error: syntax error, unexpected '&', expecting $end; Input:
&returnmacro(1-2)
^
WARNING[9417]:
 ast_expr2.fl:472 ast_yyerror: If you have questions, please refer to doc/tex/channelvariables.tex in the asterisk source.
WARNING[9417]:
 ael/pval.c:2662 check_pval_item: Warning: file /apps/asterisk/etc/extensions.ael, line 403-403: expression &returnmacro(1-2) has operators, but no variables. Interesting...
#########################################################################

#2: "Arg to 'return' is subject to math evaluation when it should not be"
I tested using 'Return(${xx}).  It works with any string. It no longer generates a Warning.  This is nice.
I also tested using 'return ${xx}'.  This now gives a syntax error when extensions.ael tries to load; I guess this was what you intended with the new patch.
#########################################################################
ERROR[9417]: ael.y:840 ael_yyerror: ==== File: /apps/asterisk/etc/extensions.ael, Line 18, Cols: 15-23: Error: syntax error, unexpected word, expecting ';'
#########################################################################
I still think it would be best to let the parser map 'return ${xx}' directly to 'Return(${xx})' instead of generating a syntax error.
The way it stands now:
If somebody wants to return from a macro without arguments there is a choice of:
'Return()'   or   'return'.
But if somebody wants to return with an argument it is necessary to use:
'Return(arg)'.
This inconsistency may cause confusion for some!
By: Bradley Watkins (marquis) 2010-01-27 09:13:24.000-0600

Now that tilghman put in a menuselect option to rebuild parsers (REBUILD_PARSERS under Compiler Flags), did you enable that?
By: Chris Walton (crjw) 2010-01-27 09:54:59.000-0600

Oops.  No, I did not realize I was supposed to do change the compiler flags.
I will try again (sometime in the next 24 hours).
By: Bradley Watkins (marquis) 2010-01-27 19:31:42.000-0600

Yes, you will have to do that to regenerate the flex/bison stuff.  Thankfully Tilghman made that change so it's a lot easier to do that now.  If you have the dreaded 'XXX' instead of '[ ]' when you go to enable that flag, you'll have to make sure you have flex/bison installed and a reasonably recent version.

In regards to the return/Return() issue you mention, that's actually what I was trying to do once it was pointed out by you and Tilghman that literal strings as well as other constructs didn't work.

But the work involved in making the lexer and parser do that was a whole lot more than just allowing Return(arbitrary stuff here) because AEL already has the code to deal with that when calling applications.

So this syntax is by far the path of least resistance, and also much less likely to introduce unforseen regressions.

Unfortunately AEL's lexer/parser are woolly places to be poking around and I like to avoid breaking other peoples' dialplans. :)
By: Chris Walton (crjw) 2010-01-27 21:55:25.000-0600

Thanks Marquis, it looks better after selecting "REBUILD_PARSERS"!
A couple of issues though:

I have a string in the "globals" section that fails to parse; it caused no trouble before.
I did not yet determine if this is a result of the patch or the result of another bug that surfaced after rebuilding the parsers.
The code that causes problems is this:
globals {
   TEST_EXTENSIONS=SIP/x300b&SIP/x400&SIP/x450;
};
The parser no longer like the ampersands.
Normally I would use 'Set()' to set a variable when the string contains non-alphanumeric characters.  But 'Set()' is an "application", and applications can't be used in the globals section of extensions.ael;  too bad.

I am now able to do "direct assignment" to a variable.
But I still have a runtime problem if the returned value contains commas.
I tested with minus signs and plus signs; these are fine.
The problem with the commas lies in the fact the the code is using 'MSet()'.
MSet allows for multiple variable assignments and expects each assignment will be separated by a comma.
  MSet syntax: MSet(name1=value1[,name2=value2[,...]])
If direct assignment were to use 'Set()' instead of 'MSet()', this problem would go away.
Here is my test code:
macro returnmacro(xx) {
       Set(xx=1,2);
       Return(${xx});
}
...
610 =>{
       FOO=&returnmacro(zz)
       NoOp(GOSUB_RETVAL: ${GOSUB_RETVAL});
       NoOp(FOO:          ${FOO});
       Hangup;
}
And here is the console output:
############################################
Executing [610@home1:1] Gosub("SIP/x300b-00000008", "returnmacro,s,1(zz)")
Executing [s@returnmacro:1] MSet("SIP/x300b-00000008", "LOCAL(xx)=zz")
Executing [s@returnmacro:2] Set("SIP/x300b-00000008", "xx=1,2")
Executing [s@returnmacro:3] Return("SIP/x300b-00000008", "1,2")
Executing [610@home1:2] MSet("SIP/x300b-00000008", "FOO=1,2")
[Jan 28 03:24:50] WARNING[28572]: pbx.c:9520 pbx_builtin_setvar_multiple: MSet: ignoring entry '2' with no '=' (in 610@home1:2
Executing [610@home1:3] NoOp("SIP/x300b-00000009", "GOSUB_RETVAL: 1,2")
Executing [610@home1:4] NoOp("SIP/x300b-00000009", "FOO:          1")
Executing [610@home1:5] Hangup("SIP/x300b-00000008", "")
############################################

Would there be any ramifications of making the direct assignment code use 'Set()' instead of 'Mset()'?
By: Chris Walton (crjw) 2010-01-28 00:03:20.000-0600

I recompiled with "REBUILD_PARSERS" enabled but with no patch.
My problem with the ampersands in the "globals" section went away.
This implies that the patch does indeed have a minor side effect.
This is something I can easily work around.  I am not sure how many other people might be impacted.
By: Bradley Watkins (marquis) 2010-01-28 06:25:38.000-0600

That is definitely an issue, and not one I think I or anybody else is really willing to live with.

So I will try to resolve this.

I don't think I've mentioned it yet, but thanks a lot for the testing.  It's helping to uncover some problems and get them resolved so this feature can eventually be committed.
By: Chris Walton (crjw) 2010-01-29 16:23:49.000-0600

Marquis,
I will not have access to my test hardware for the next 7 days.
If you release another patch during this time, I will happily test it on Feb 6 or 7.
Don't expect to hear much from me in the meantime; this does not mean I am losing interest!
By: Corey Farrell (coreyfarrell) 2017-12-14 13:46:13.669-0600

Are you interested in pursuing this further?  If so the patch will need to be rebased so it can apply the the current {{master}} branch and it will need to go through code review.

----

Thanks for the contribution! If you'd like your contribution to be included faster, you should submit your patch for code review by the Asterisk Developer Community. To do so, please follow the Code Review \[1\] instructions on the wiki. Be sure to:
* Verify that your patch conforms to the Coding Guidelines \[2\]
* Review the Code Review Checklist \[3\] for common items reviewers will look for
* If necessary, provide tests for the Asterisk Test Suite that verify the correctness of your patch \[4\]

When ready, submit your patch and any tests to Gerrit \[5\] for code review.

Thanks!

\[1\] https://wiki.asterisk.org/wiki/display/AST/Code+Review
\[2\] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
\[3\] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist
\[4\] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation
\[5\] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage
By: Asterisk Team (asteriskteam) 2018-01-02 08:49:52.723-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines