diff options
author | VladimirTechMan <VladimirTechMan@gmail.com> | 2019-08-11 14:10:54 +0300 |
---|---|---|
committer | Chris Dickens <christopher.a.dickens@gmail.com> | 2020-01-02 19:02:26 -0800 |
commit | 5d0d0a58ed3ea813200b83d69e28a3ea24e86f01 (patch) | |
tree | 408740a337c36d263140c249551ed1549d21e1eb /libusb/io.c | |
parent | 6d037d0625a1e8a68d6bcd0f9f35f9026f97b2bd (diff) | |
download | libusb-5d0d0a58ed3ea813200b83d69e28a3ea24e86f01.tar.gz |
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>
Diffstat (limited to 'libusb/io.c')
0 files changed, 0 insertions, 0 deletions