On 2012.06.17 14:27, Xiaofan Chen wrote:
> Here are the results for clang analyzer under Mac OS X.
>
>    CC       libusb_1_0_la-core.lo
> ../../libusbx/libusb/core.c:700:4: warning: Function call argument is
> an uninitialized value
>                          libusb_free_device_list(devs, 1);
>                          ^                       ~~~~
> ../../libusbx/libusb/core.c:706:2: warning: Function call argument is
> an uninitialized value
>          libusb_free_device_list(devs, 1);
>          ^                       ~~~~
> 2 warnings generated.

I'm a bit bothered that I'm not seeing those in Clang/MinGW, which I 
compiled from a fairly recent Clang/git tree.

On the other hand, there's a chance that the path that leads to the 
uninitialized value comes from the darwin backend then. It could even be 
tied to Trac #30/libusb #136 [1], though I'd expect a crash more than a 
leak there.

Can you launch another Clang run and send the html files generated? They 
should clarify whether the Darwin backend is involved in the above or not.

> ../../libusbx/libusb/sync.c:84:11: warning: Result of 'malloc' is
> converted to a pointer of type 'unsigned char', which is incompatible
> with sizeof operand type 'struct libusb_control_setup'
>          buffer = malloc(LIBUSB_CONTROL_SETUP_SIZE + wLength);
>                   ^~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 warning generated.

VS2010 is unhappy about that assignation too, so I'll fix it, along with 
the dpfp ones below. I'd expect Clang/MinGW to report the same error 
though, which it doesn't...

>    CC       libusb_1_0_la-darwin_usb.lo
> ../../libusbx/libusb/os/darwin_usb.c:1713:11: warning: Access to field
> 'cfSource' results in a dereference of a null pointer (loaded from
> variable 'hpriv')
>        if (hpriv->cfSource) {
>            ^~~~~
> 1 warning generated.

I think I have a fairly good idea of how we should address that one, but 
the html output from Clang would also help here.

> clang: warning: argument unused during compilation: '-std=gnu99'

As per my other reply to Sean, no idea why -std=gnu99 would end in 
ldflags. Don't care much about it, so if anybody is interested, they can 
look it up and submit a patch.

>    CC       dpfp.o
> ../../libusbx/examples/dpfp.c:167:23: warning: Result of 'malloc' is
> converted to a pointer of type 'unsigned char', which is incompatible
> with sizeof operand type 'struct libusb_control_setup'
>          unsigned char *buf = malloc(LIBUSB_CONTROL_SETUP_SIZE + 1);
>          ~~~~~~~~~~~~~~~      ^~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 warning generated.
>    CCLD     dpfp
> clang: warning: argument unused during compilation: '-std=gnu99'
>    CC       dpfp_threaded-dpfp_threaded.o
> ../../libusbx/examples/dpfp_threaded.c:196:23: warning: Result of
> 'malloc' is converted to a pointer of type 'unsigned char', which is
> incompatible with sizeof operand type 'struct libusb_control_setup'
>          unsigned char *buf = malloc(LIBUSB_CONTROL_SETUP_SIZE + 1);
>          ~~~~~~~~~~~~~~~      ^~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 warning generated.
>    CCLD     dpfp_threaded

Regards,

/Pete

[1] https://sourceforge.net/apps/trac/libusbx/ticket/30



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Reply via email to