[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