[Home]

Summary:ASTERISK-01736: Macros do not clear argument variables when calling other macros
Reporter:ewieling (ewieling)Labels:
Date Opened:2004-06-01 09:17:02Date Closed:2011-06-07 14:10:50
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:You can call a macro from within a macro, however when you do this the ARG* variables are not cleared.

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

[default]
exten => 87,1,Macro(main,FNORD)

[macro-main]
exten => s,1,NoOp(macro-main: ARG1=${ARG1})
exten => s,2,Macro(sub)
                                                                                                                             
[macro-sub]
exten => s,1,NoOp(macro-sub: ARG1=${ARG1})

   -- Starting simple switch on 'Zap/2-1'
   -- Executing Macro("Zap/2-1", "main|FNORD") in new stack
   -- Executing NoOp("Zap/2-1", "macro-main: ARG1=FNORD") in new stack
   -- Executing Macro("Zap/2-1", "sub") in new stack
   -- Executing NoOp("Zap/2-1", "macro-sub: ARG1=FNORD") in new stack
   -- Hungup 'Zap/2-1'
Comments:By: Mark Spencer (markster) 2004-06-01 14:41:21

The behavior is correct.  Only arguments that are specified are backed up and
restored.  I see no reason whatsoever to clear the other arguments:

[macro-bar]
exten => s,1,Noop(${ARG1}/${ARG2})

[macro-foo]
exten => s,1,Noop(${ARG1}/${ARG2})
exten => s,2,Macro(bar,bar1);
exten => s,3,Noop(${ARG1}/${ARG2})

[default]
exten => 102,1,Macro(foo,foo1,foo2)


produces the correct output:

   -- Executing Macro("Zap/1-1", "foo|foo1|foo2") in new stack
   -- Executing NoOp("Zap/1-1", "foo1/foo2") in new stack
   -- Executing Macro("Zap/1-1", "bar|bar1") in new stack
   -- Executing NoOp("Zap/1-1", "bar1/foo2") in new stack
   -- Executing NoOp("Zap/1-1", "foo1/foo2") in new stack
By: Denis Pantsyrev (StuxForce) 2015-05-12 02:22:48.755-0500

I think that it's wrong behavior.
Macro2, called from macro1, must not see the arguments passed to macro1.

For the Mark Spencer's comment it must be like:

bq.– Executing NoOp("Zap/1-1", "bar1/") in new stack

instead of

bq.– Executing NoOp("Zap/1-1", "bar1/foo2") in new stack

This behavior makes it difficult to verify the number of arguments passed to the macro