[asterisk-dev] [Code Review] chan_sip code cleanup

jrose reviewboard at asterisk.org
Thu Jun 21 15:48:03 CDT 2012


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



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1993/#comment12359>

    As a personal preference, I think function names should be more specific rather than less specific unless they are just getting cumbersomely large (which I don't think add_diversion_header would be considered large).
    
    The same note applies to add_date and add_expires.  I think they would be better as add_date_header and add_expires_header.  Functions that mess with headers I feel should have the word 'header' in there somewhere.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1993/#comment12361>

    This seems to be a minor optimization (to avoid redeclaring the character pointer) that doesn't really have anything to do with other stuff in the patch.  I'd recommend splitting optimizations like this into a separate patch.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1993/#comment12357>

    Just another bit of inappropriate white space that you got near.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1993/#comment12356>

    Since you are changing this, you might as well make it fit the style guidelines.
    
    Remove the trailing white space, add braces to the condition.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1993/#comment12351>

    I don't really see why this kind of minor optimization is being grouped with some of the other stuff in this patch. I'm also not to fond of variables with less than useful names like 'ptr' for a character pointer... though if it's going to be recycled like this, there probably isn't a real problem with that. Maybe something like delimiter_ptr or something would be more appropriate than ptr.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1993/#comment12350>

    You have changes that are pretty close to these blobgs... might as well clean up the white space.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1993/#comment12349>

    Remove the extra white space.


I've just taken a brief minute look at this so far, but I'm just going to point out that there are a lot of changes in this patch.  Would you be opposed to breaking this up into a series of smaller patches? There are a number of benefits to this, among them being that if you introduce a problem with these changes that causes a test failure or something we can reproduce later on, we'll be able to pinpoint which change specifically causes this more easily. Another benefit would be that smaller reviews tend to be approved much more quickly.

- jrose


On June 19, 2012, 10:08 p.m., gareth wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1993/
> -----------------------------------------------------------
> 
> (Updated June 19, 2012, 10:08 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This is the first part split out from the much larger patch at https://reviewboard.asterisk.org/r/1976/ - it contains just the various chan_sip code cleanups.
> 
> - struct sip_refer converted to use the stringfields API.
> 
> - sip_{refer|notify}_allocate -> sip_{notify|refer}_alloc to match other *alloc functions.
> 
> - Replace get_msg_text, get_msg_text2 and get_pidf_body -> No, not get_pidf_msg_text_body3 but get_content, to match add_content.
> 
> - get_body doesn't get the request body, renamed to get_content_line.
> 
> - get_body_by_line doesn't get the body line, and is just a simple if test. Moved code inline and removed function.
> 
> - Remove camelCase in struct sip_peer peer state variables, onHold -> onhold, inUse -> inuse, inRinging -> ringing.
> 
> - Remove camelCase in struct sip_request rlPart1 -> rlpart1, rlPart2 -> rlpart2.
> 
> - Rename instances of pvt->randdata to pvt->nonce because that is what it is, no need to update struct sip_pvt because _it already has a nonce field_.
> 
> - Removed struct sip_pvt randdata stringfield.
> 
> - Remove useless (and inconsistent) 'header' suffix on variables in handle_request_subscribe.
> 
> - Use ast_strdupa on Event header in handle_request_subscribe to avoid overly complicated strncmp calls to find the event package.
> 
> - Move get_destination check in handle_request_subscribe to avoid duplicate checking for packages that don't need it.
> 
> - Move extension state callback management in handle_request_subscribe to avoid duplicate checking for packages that don't need it.
> 
> - Remove duplicate append_date prototype.
> 
> - Rename append_date -> add_date to match other add_xxx functions.
> 
> - Added add_expires helper function, removed code that manually added expires header.
> 
> - Remove _header suffix on add_diversion_header (no other header adding functions have this).
> 
> - Don't pass req->debug to request handle_request_XXXXX handlers if req is also being passed.
> 
> - Don't pass req->ignore to check_auth as req is already being passed.
> 
> - Don't create a subscription in handle_request_subscribe if p->expiry == 0.
> 
> - Don't walk of the back of referred_by_name when splitting string in get_refer_info
> 
> - Remove duplicate check for no dialog in handle_incoming when sipmethod == SIP_REFER, handle_request_refer checks for that.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 369065 
>   /trunk/channels/sip/include/sip.h 369065 
>   /trunk/channels/sip/security_events.c 369065 
> 
> Diff: https://reviewboard.asterisk.org/r/1993/diff
> 
> 
> Testing
> -------
> 
> It compiles.
> 
> 
> Thanks,
> 
> gareth
> 
>

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


More information about the asterisk-dev mailing list