[asterisk-dev] [Code Review] ParkedCall can now be 'exten at parkinglot' instead of just 'exten'

rmudgett reviewboard at asterisk.org
Fri May 6 11:45:45 CDT 2011



> On 2011-05-06 11:32:06, David Vossel wrote:
> > /trunk/main/features.c, lines 4503-4508
> > <https://reviewboard.asterisk.org/r/1209/diff/1/?file=16375#file16375line4503>
> >
> >     If data is something like 10 at whatever, then what does atoi("10 at whatever") do?  I didn't think atoi works like that.

atoi() will return 10.  It stops parsing on the first invalid character in the string.  If the string was "alpha", atoi() returns 0.


- rmudgett


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


On 2011-05-06 09:12:12, jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1209/
> -----------------------------------------------------------
> 
> (Updated 2011-05-06 09:12:12)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This feature addition allows the ParkedCall application to include the name of a parkinglot so that the caller can use this application on a specific parkinglot rather than just jumping to whichever parkinglot is already bound to the requesting channel.
> 
> 
> This addresses bug 18777.
>     https://issues.asterisk.org/view.php?id=18777
> 
> 
> Diffs
> -----
> 
>   /trunk/CHANGES 317381 
>   /trunk/main/features.c 317381 
> 
> Diff: https://reviewboard.asterisk.org/r/1209/diff
> 
> 
> Testing
> -------
> 
> Tested with multiple parkinglots of various names to make sure it searches the right parkinglots (parkinglot names have to be used, not their context names).  Also tested to make sure it didn't interfere with the normal behavior with no specified parkinglot (it was segfaulting, for what was an obvious reason, so testing was useful).
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110506/2c1683f6/attachment.htm>


More information about the asterisk-dev mailing list