[PATCH 0/2] Fix Clang warnings

[Pete Batard]

Just a couple of patches for warnings raised by Clang/MinGW. These only 
affect Windows/xusb.

With these applied, below is the output from Clang in MinGW:

------------------------------------------------------------------------
$ scan-build make -j2
make  all-recursive
make[1]: Entering directory `/d/libusbx'
Making all in libusb
make[2]: Entering directory `/d/libusbx/libusb'
   CC     libusb_1_0_la-core.lo
   CC     libusb_1_0_la-descriptor.lo
   CC     libusb_1_0_la-io.lo
io.c:1864:8: warning: Call to 'malloc' has an allocation size of 0 bytes
         fds = malloc(sizeof(*fds) * nfds);
               ^      ~~~~~~~~~~~~~~~~~~~
1 warning generated.
   CC     libusb_1_0_la-sync.lo
   CC     libusb_1_0_la-poll_windows.lo
   CC     libusb_1_0_la-windows_usb.lo
   GEN    libusb-1.0.lo
   CC     libusb_1_0_la-threads_windows.lo
   CCLD   libusb-1.0.la
Creating library file: .libs/libusb-1.0.dll.a
make[2]: Leaving directory `/d/libusbx/libusb'
Making all in doc
make[2]: Entering directory `/d/libusbx/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/d/libusbx/doc'
Making all in examples
make[2]: Entering directory `/d/libusbx/examples'
   CC     listdevs.o
   CC     xusb.o
   CCLD   listdevs.exe
./.libs/lt-listdevs.c:692:11: warning: Value stored to 'len' during its 
initialization is never read
       int len = strlen (new_value);
           ^     ~~~~~~~~~~~~~~~~~~
   CCLD   xusb.exe
1 warning generated.
./.libs/lt-xusb.c:692:11: warning: Value stored to 'len' during its 
initialization is never read
       int len = strlen (new_value);
           ^     ~~~~~~~~~~~~~~~~~~
1 warning generated.
make[2]: Leaving directory `/d/libusbx/examples'
make[2]: Entering directory `/d/libusbx'
make[2]: Leaving directory `/d/libusbx'
make[1]: Leaving directory `/d/libusbx'
scan-build: 3 bugs found.
scan-build: Run 'scan-view /tmp/scan-build-2012-03-28-2' to examine bug 
reports.
------------------------------------------------------------------------

The lt- ones are libtool issues which only libtool can (and hopefully 
will) address as we're not invoking strlen in our code.

As far as I can tell, the one in io.c is a false positive, as nfds 
should never be zero. Maybe there's a way to silence Clang on that, but 
I don't want to touch core for 1.0.9 unless needed. Now, if we can ever 
get a zero value there, we may have an issue, as the behaviour of 
malloc(0) is undetermined, and it seems gcc will return a pointer that 
should not be dereferenced [1].

Regards,

/Pete

PS: I also pushed a fix to address the missing xusb in the VS2005 
project files

[1] http://bytes.com/topic/c/answers/578467-what-malloc-0-should-returns