* http://sourceforge.net/mailarchive/message.php?msg_id=29418038
* core.c:700:4: warning: Function call argument is an uninitialized value
* darwin_usb.c:1713:11: warning: Access to field 'cfSource' results in a
dereference of a null pointer (loaded from variable 'hpriv')
* sync.c/dpfp.c/dpfp_threaded.c: warning: Result of 'malloc' is converted
to a pointer of type 'unsigned char', which is incompatible with sizeof
operand type
The OpenBSD C compiler generates a warning for every use of sprintf()
and for a good reason. Reported in http://marc.info/?m=133376187514495
Reported-by: Xiaofan Chen <xiaofanc@gmail.com>
Compiling with gcc-4.6 results in the following warnings:
os/linux_usbfs.c: In function 'op_get_configuration':
os/linux_usbfs.c:1144:6: warning: variable 'r' set but not used ...
os/linux_usbfs.c: In function 'op_handle_events':
os/linux_usbfs.c:2091:40: warning: 'status' may be used uninitialized ...
os/linux_usbfs.c:2044:6: note: 'status' was declared here
dpfp.c: In function 'save_to_file':
dpfp.c:228:9: warning: variable 'ignore' set but not used ...
dpfp_threaded.c: In function 'save_to_file':
dpfp_threaded.c:257:9: warning: variable 'ignore' set but not used ...
This patch fixes these. (The second comes from handle_control_completion()
which gcc seems to inline into op_handle_events().)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[stuge: Add fixes for dpfp examples and update source references]
Under Windows, a variety of compilers and configurations are available,
meaning that the manner of parameter passing (e.g. registers vs stack)
can vary.
Match the Windows API calling convention and document this appropriately.
This calling convention will be used regardless of the configuration of
the user's development platform.
The only user-level complication is that all functions used as libusb
callbacks must use the same calling convention as libusb. The
LIBUSB_CALL macro is provided to make this easy.
Signed-off-by: Michael Plante <michael.plante@gmail.com>
Signed-off-by: Pete Batard <pbatard@gmail.com>
[dsd: slight change of strategy, add documentation]
Due to variable-sized structures, this involved changing allocation
mechanism. All transfers must now be allocated and freed through
libusb.
A synchronous function is missing, and I could do with writing a few
more helper functions to simplify things.
Leads to some hefty API changes. Now we're much more similar to the
Linux kernel model.
Problems with dealing with asynchronous control transfers are passed
on to the user, basically you must allocate a buffer, start with the
setup, and put the data after. This won't make much sense until
documented (soon...)
Now refer to everything as "transfers" as consistent with the USB spec
libusb_transfer is now a kind of transfer handle. To reduce confusion
with libusb_bulk_transfer and libusb_control_transfer, those have been
renamed to libusb_{control,bulk}_transfer_request.
Lots of libusb apps I write are simple test apps not intended to be real
apps. Having a function available to quickly locate my device will be
handy in such situations.
libusb_find_devices and libusb_get_devices are no more
libusb_get_device_list obtains a list of libusb_device structures for all
known devices in the system.
Each libusb_device now has a reference count, defaulting to 1 on
instantiation. The reference count of 1 refers to the fact that it is
present in the list in this scenario.
Opening a device adds a pointer to the libusb_device structure in the
handle, so that also adds a reference. Closing the device removes that
reference.
The function to free the device list can optionally unref all the devices
inside.
In future we will make the libusb_device instances all "global" so that if
the app calls get_device_list twice it actually gets the same libusb_device
structure references back. This way we can start to track disconnects, and
we can investigate adding a unique "session ID" to each libusb_device, an
identifier guaranteed to be unique to that device until reboot.
Instead of timers, add a mechanism for informing the parent app when the
next timeout is due to happen, so that it can call us at that time.
As we no longer use signals, signalfd has also been removed.
fpi changed to usbi.
We should not expose structures with prefix "usb_" in the public
namespace as it is quite likely there will be some conflict somewhere.
Instead, using "libusb_" should be safer.
These are easiest to construct on the stack, but in the async case it is
likely that the submitting function returns (hence stack is destroyed)
before URB completion.
