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

[Johannes E. <joh...@er...>]

On Tue, May 02, 2006, Graeme Gill <gr...@ar...> wrote:
> 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.

Yes, this is one of the things that is being fixed in libusb 1.0

int libusb_bulk(struct libusb_bulk_request *bulk, size_t *transferred_bytes);

> 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).

What version of libusb are you using?

I'm pretty sure there was a bug similar to this that was resolved.

It's not exactly clear to me what your patch is doing since some parts
look completely wrong.

JE