On Aug 26, 2013, at 8:18 PM, Nathan Hjelm <hje...@me.com> wrote:
>
> On Aug 26, 2013, at 5:12 PM, Sean McBride <s...@rogue-research.com> wrote:
>
>> On Mon, 26 Aug 2013 22:33:10 +0000, Nathan Hjelm said:
>>
>>> Hmm, the conclusion is wrong. If ret > -1 the cached_device is always
>>> not NULL. I should probably change:
>>>
>>> if (ret < 0 || (cached_device && !cached_device->can_enumerate)) {
>>>
>>> to:
>>>
>>> if (ret < 0 || !cached_device->can_enumerate) {
>>>
>>> to reflect this.
>>
>> That change would silence the warning, and is IMHO an appropriate fix if
>> you're 100% sure that 'cached_device' can indeed never be null when ret >= 0.
>>
>> I've stared at the code for a couple of seconds, and am not fully convinced
>> myself. After all, the very first thing darwin_get_cached_device() does is:
>> ret = 0;
>> *cached_out = NULL;
>>
>> If those initial conditions are not changed (in some freaky branch) then the
>> quoted checks above are not equivalent. But I trust you know the code well!
>
>
> At one point there was a change that the return code was 0 but cached_out was
> NULL. Since that is no longer the case and clang is complaining I cleaned up
> the *cached_out = NULL and the if check. You should no longer get a warning.
Bah! After I committed that I realized the *cached_out = NULL does something
important. Restored that and fixed some return codes.
-Nathan
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
