[asterisk-dev] [Code Review] 4533: clang compiler warning: -Wtautological-compare

[Diederik de Groot]

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

(Updated March 29, 2015, 7:10 p.m.)


Review request for Asterisk Developers.


Bugs: ASTERISK-24917
    https://issues.asterisk.org/jira/browse/ASTERISK-24917


Repository: Asterisk


Description
-------

clang's static analyzer will throw quite a number warnings / errors during compilation, some of which can be very helpfull in finding corner-case bugs

clang compiler warning:-Wtautological-compare

Changes:
/branches/13/channels/pjsip/dialplan_functions.c:869
len is of type size_t, which is unsigned. It will not be able to hold a value < 0

/branches/13/funcs/func_curl.c:174
Not a 100% sure how to do this correctly. But assiging a negative value is problematic. Extending the enum in curl/curl.h is not possible either. I opted to use the enum last entry (CURL_LAST) which is currently not used for any thing. Another option would be to use one of the OBSOLETE VALUES like 16. Neither way is very nice though.

/branches/13/include/asterisk/app.h:988
Needed to convey the error state returned by res/res_stasis_recording.c:stasis_app_recording_if_exists_parse

/branches/13/include/asterisk/cel.h:77
Added to convey not-found or error state. Not sure which name would be prefered for such an enum value.

/branches/13/main/cel.c:536
Return actual enum instead of -1,l which can not be conveyed by this enum.

/branches/13/main/enum.c:260
dn_expand return signed int

/branches/13/main/event.c:202
enum type cannot be < 0

/branches/13/main/indications.c:362
tone_data.freq1 and freq2 are unsigned int's so no need to check if < 0. Not sure what should happend when freq1 / freq2 are 0 already... (needs recheck by source owner)

/branches/13/main/presencestate.c:293
Should use the actual enum value for INVALID State

/branches/13/main/security_events.c:432/890/1176/
enum event_type cannot be <0

/branches/13/main/udptl.c:365/649/661
encode_length returns and unsigned int, so checking if < 0 does not make sence. Not 100% if encode_length has side effects, so left the actual call the this function in place. (Needs to be rechecked by code-owner)

/branches/13/res/res_pjsip_exten_state.c:411
Used a temporary int variable to be able to check the return value from ast_hint_presence_state.. Not very nice, but did not want to change the signature of this function.

/branches/13/res/res_stasis_playback.c:634
operation is enum and cannot be < 0

/branches/13/res/res_stasis_recording.c:598/604
recording->state / operation is enum and cannot be < 0

/branches/13/res/res_security_log.c:992
enum event_type cannot be <0

use of ARRAY_IN_BOUNDS with enum results in tautological comparison for the lower limit which is always true.


Diffs (updated)
-----

  /branches/13/res/res_stasis_recording.c 433444 
  /branches/13/res/res_stasis_playback.c 433444 
  /branches/13/res/res_pjsip_exten_state.c 433444 
  /branches/13/res/ari/resource_channels.c 433444 
  /branches/13/res/ari/resource_bridges.c 433444 
  /branches/13/main/udptl.c 433444 
  /branches/13/main/security_events.c 433444 
  /branches/13/main/presencestate.c 433444 
  /branches/13/main/indications.c 433444 
  /branches/13/main/event.c 433444 
  /branches/13/main/enum.c 433444 
  /branches/13/main/cel.c 433444 
  /branches/13/main/app.c 433444 
  /branches/13/include/asterisk/utils.h 433444 
  /branches/13/include/asterisk/logger.h 433444 
  /branches/13/include/asterisk/cel.h 433444 
  /branches/13/include/asterisk/app.h 433444 
  /branches/13/funcs/func_curl.c 433444 
  /branches/13/channels/pjsip/dialplan_functions.c 433444 
  /branches/13/channels/chan_skinny.c 433444 

Diff: https://reviewboard.asterisk.org/r/4533/diff/


Testing
-------


Thanks,

Diederik de Groot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150329/3d560184/attachment.html>