[asterisk-dev] [Code Review] Mask arguments of previous invocations of Gosub

[Mark Michelson]

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



/trunk/tests/test_gosub.c
<https://reviewboard.asterisk.org/r/561/#comment3771>

    I suppose this is worth discussing. Should failures that occur due to memory allocation prior to the real meat of the test be reported as a test failure or as done here with AST_TEST_NOT_RUN? I can see valid reasons for both ways, so I'll leave it up to someone else to make that decision.



/trunk/tests/test_gosub.c
<https://reviewboard.asterisk.org/r/561/#comment3769>

    Using ast_stdup like this will cause a single-byte memory leak every time this test is run.



/trunk/tests/test_gosub.c
<https://reviewboard.asterisk.org/r/561/#comment3770>

    You can break at this point.


- Mark


On 2010-03-16 17:45:49, Tilghman Lesher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/561/
> -----------------------------------------------------------
> 
> (Updated 2010-03-16 17:45:49)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The current behavior of Gosub is that it does not mask out previous arguments.  The problem with this is that for any subroutine with optional arguments, arguments from previous stack levels could influence how the newest stack level executes.
> 
> 
> This addresses bug 16758.
>     https://issues.asterisk.org/view.php?id=16758
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/app_stack.c 252838 
>   /trunk/tests/test_gosub.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/561/diff
> 
> 
> Testing
> -------
> 
> Unit test written that verifies this new behavior, as well as verifying several other behaviors of the Gosub suite of applications.
> 
> 
> Thanks,
> 
> Tilghman
> 
>