Pete Batard wrote: > > The bug is that the Windows backend requires a libusb_device * to be > > unref:ed before libusb_get_device_list() reports system changes, > > while other backends do not have this limitation and it is documented > > that libusb_get_device_list() does not have this limitation. .. > That other backends have decided to pre-empt something that > rightfully belongs to hotplug, by implementing part of the device > refresh that belongs there, is their choice
Other backends did not choose to do this. The specification (the API) says that they must, and hotplug or not changes nothing. It's about what the libusb API provides it's callers with, and the Windows backend doesn't really deliver because of this bug and with a few others. (That difficult-to-spot enumeration bug, cross-thread cancellation, and who knows what else.) Yes, the experimental backend will have bugs, but you seem to claim that this isn't really a bug while it is really obvious by now that it is. > >> you're asking for hotplug before we implement hotplug. > > > > No, I'm confirming that the non-hotplug-supporting API has a bug in > > the Windows backend. > > Except, you hadn't confirmed anything at this point, as the only > actual verifiable data The data I used (and all that's needed) was Uri's description of what he did and what happened, along with Hans extended explanation of the problem. Because I know how the libusb API is supposed to work (and you know too, since Hans quoted the documentation) no further data or testing is needed to confirm that the Windows backend indeed has a bug here. You can of course view that any way you like, and see it as receiveable (or not) as you like, but that doesn't change the facts. //Peter ------------------------------------------------------------------------------ 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
