Hi,
On 09/18/2012 12:56 AM, Pete Batard wrote:
> On 2012.09.17 09:44, Hans de Goede wrote:
>> my patch those would return "**UNKNOWN**", and know if the amount
>> transfered is small enough they may return a "LIBUSB_TRANSFER_FOO" string.
>
> And now I realize that libusb_transfer_status is an enum
On 2012.09.17 09:44, Hans de Goede wrote:
> my patch those would return "**UNKNOWN**", and know if the amount
> transfered is small enough they may return a "LIBUSB_TRANSFER_FOO" string.
And now I realize that libusb_transfer_status is an enum, and not a set
of negative defines... This changes th
Hi,
On 09/15/2012 04:21 PM, Pete Batard wrote:
> On 2012.09.15 12:13, Chuck Cook wrote:
>> On 09/15/2012 06:31 AM, Hans de Goede wrote:
>>> Note that for the code 0 which means success resp. completed we have an
>>> overlap in the codes. This is not a problem since normally one would not
>>> call
On 2012.09.15 12:13, Chuck Cook wrote:
> On 09/15/2012 06:31 AM, Hans de Goede wrote:
>> Note that for the code 0 which means success resp. completed we have an
>> overlap in the codes. This is not a problem since normally one would not
>> call libusb_error_name on success / normal completion.
>
How about returning NO_ERROR for code >= 0
and UNKNOWN_ERROR when code < 0 and doesn't match a defined error
On 09/15/2012 06:31 AM, Hans de Goede wrote:
> Note that for the code 0 which means success resp. completed we have an
> overlap in the codes. This is not a problem since normally one would
I don't know how wise it is to mix the two different namespaces.
//Peter
--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite
Note that for the code 0 which means success resp. completed we have an
overlap in the codes. This is not a problem since normally one would not
call libusb_error_name on success / normal completion.
Signed-off-by: Hans de Goede
---
libusb/core.c | 26 +-
libusb/libusb.
