[asterisk-dev] [Code Review]: Turn HANGUPCAUSE into a function and add cause translations

opticron reviewboard at asterisk.org
Tue Jul 10 19:36:43 CDT 2012



> On July 10, 2012, 4:15 p.m., Mark Michelson wrote:
> > trunk/main/channel_internal_api.c, lines 1192-1198
> > <https://reviewboard.asterisk.org/r/2025/diff/2/?file=29946#file29946line1192>
> >
> >     Coding guidelines state to put the opening curly bracket for functions on a separate line from the function declaration.

Fixed.


> On July 10, 2012, 4:15 p.m., Mark Michelson wrote:
> > trunk/funcs/func_hangupcause.c, line 209
> > <https://reviewboard.asterisk.org/r/2025/diff/2/?file=29942#file29942line209>
> >
> >     If you provide a NULL pointer for the callback function, then ao2_callback() will automatically match all objects in the container.
> >     
> >     Also, OBJ_MULTIPLE will do nothing here since OBJ_NODATA renders it moot.
> 
> rmudgett wrote:
>     No.  OBJ_MULTIPLE is needed.  It keeps the traversal going after the first found object.
> 
> Mark Michelson wrote:
>     There are no found objects. The callback always returns 0 and never CMP_MATCH.
> 
> Mark Michelson wrote:
>     Oops, got my callbacks mixed up. It's always returning CMP_MATCH, not 0. So yeah, OBJ_MULTIPLE is required.

Simplified to use the same form as elsewhere in the codebase.


> On July 10, 2012, 4:15 p.m., Mark Michelson wrote:
> > trunk/funcs/func_hangupcause.c, line 72
> > <https://reviewboard.asterisk.org/r/2025/diff/2/?file=29942#file29942line72>
> >
> >     I can't think of any other applications that have a _ in the name. Go with CamelCase for this.

Fixed.


> On July 10, 2012, 4:15 p.m., Mark Michelson wrote:
> > trunk/funcs/func_hangupcause.c, line 59
> > <https://reviewboard.asterisk.org/r/2025/diff/2/?file=29942#file29942line59>
> >
> >     redness

Fixed.


- opticron


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


On July 9, 2012, 3:24 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2025/
> -----------------------------------------------------------
> 
> (Updated July 9, 2012, 3:24 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This introduces two new functions and an application: one function to access the list of channels that have provided technology-specific cause information, one function to access the cause information itself, and a new application to clear that cause information.
> 
> This also introduces storage of and access to the per-channel translated Asterisk cause information.
> 
> 
> This addresses bug SWP-4739.
>     https://issues.asterisk.org/jira/browse/SWP-4739
> 
> 
> Diffs
> -----
> 
>   trunk/channels/chan_dahdi.c 369796 
>   trunk/channels/chan_iax2.c 369796 
>   trunk/channels/chan_sip.c 369796 
>   trunk/channels/sig_analog.c 369796 
>   trunk/channels/sig_pri.c 369796 
>   trunk/channels/sig_ss7.c 369796 
>   trunk/funcs/func_hangupcause.c PRE-CREATION 
>   trunk/include/asterisk/channel.h 369796 
>   trunk/include/asterisk/frame.h 369796 
>   trunk/main/channel.c 369796 
>   trunk/main/channel_internal_api.c 369796 
>   trunk/main/rtp_engine.c 369796 
> 
> Diff: https://reviewboard.asterisk.org/r/2025/diff
> 
> 
> Testing
> -------
> 
> Modified the current tests in the testsuite to use this new interface and they continued passing as expected.
> 
> 
> Thanks,
> 
> opticron
> 
>

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


More information about the asterisk-dev mailing list