[Libusb-win32-devel] Fundamental bug in libusb read() API ?

[Graeme G. <gr...@ar...>]

There seems to be a fundamental shortcoming in the libusb API
definition. There is no way for a call to read() to timeout and
report the number of bytes it read up to the timeout, because
the return value is used for both status reporting, and
reporting the number of bytes it reads.

By comparison, under MSWindows ReadFile() has a separate status
and number of bytes return, and under Unix, the timeout is
separated by the use of poll() or select() from the
file read() function.

The libusb read() functions in practice seem to either read a number
of bytes into the caller buffer then return the timeout error
code to signal the timeout, leaving the caller
no way of knowing how many bytes have been read into their
buffer (MSWindows), or simply discard the bytes (OSX) and
returning 0 rather than -ETIMEDOUT.

Linux is even more bizarre, it seems to not signal a timeout
at all, but returns 8 (the packet size), and reads the packet
received into the buffer, but subsequent calls to read return
the same packet, over and over. (In fact to get it to return
a timeout error at all, and stop re-reading the same packet,
I had to apply the attached patch to linux.c).

Graeme Gill.