@jwrdegoede let me make an additional argument. even if it were a buggy client
passing invalid pointers to the kernel directly (which is not the case), this
buggy client would still get a nice -EFAULT which he would have a chance to
handle.
But the current behavior of libusbx is not good, imho. just because the
IOCTL_USBFS_REAPURBNDELAY failed, the function reap_for_handle() will return
prematurely without going through those handle_*_completion. Now correct me if
i'm wrong: by not calling handle_*_completion aren't we leaving
libusb_transfer/linux_transfer_priv structures in some kind of inconsistency? I
mean, we cannot even cancel this transfer because tpriv->urbs is NULL!
The current behavior doesn't help because instead of returning the kernel error
to the client to handle, it just get stuck into a while forever.
The hacky solution i did of returning without calling libusb_free_transfer()
is, as you predicted, quite hacky and admittedly wrong. But if the tpriv->urbs
were good so that libusb_cancel_transfer() worked, then we would have been able
to free and return the error just fine, no?
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/76#issuecomment-31760314
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
