commit 5d0d0a58ed3ea813200b83d69e28a3ea24e86f01
author VladimirTechMan <VladimirTechMan@gmail.com> Sun Aug 11 14:10:54 2019 +0300
committer Chris Dickens <christopher.a.dickens@gmail.com> Thu Jan 02 19:02:26 2020 -0800
tree 408740a337c36d263140c249551ed1549d21e1eb
parent 6d037d0625a1e8a68d6bcd0f9f35f9026f97b2bd

Change the errcode argument in libusb_strerror to be of type int

It would be more convenient in practice if the type of error code
argument in libusb_strerror was declared as "int", rather than
enum libusb_error: In practice, the value for the argument almost
always comes from a value returned by libusb function, thus its
type is "int" at that point. In which case, depending on the
checks enabled when compiling the C or C++ code of applications
using libusb's API, every call to libusb_strerror often requires
explicit type casting – while not a biggie, it gets inconvenient
as the number of logging calls using libusb_strerror grows.

It is worth of noting that the "peer" function libusb_error_name
already takes the int-type argument, thus eliminating the need in
extra value casting. Aligning the signature of libusb_strerror
to be the same would also improve the consistency between those
two parts of the libusb API.

Given that libusb_strerror does a range validation of its argument
value, there should not be any real drawbacks or negative effects
from "relaxing" the type declaration from enumeration to integer.
The existing application code that already does explicit casting
to enum, will keep compiling and running like before.

Closes #606

Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>