summaryrefslogtreecommitdiff
path: root/libusb/io.c
diff options
context:
space:
mode:
authorVladimirTechMan <VladimirTechMan@gmail.com>2019-08-11 14:10:54 +0300
committerChris Dickens <christopher.a.dickens@gmail.com>2020-01-02 19:02:26 -0800
commit5d0d0a58ed3ea813200b83d69e28a3ea24e86f01 (patch)
tree408740a337c36d263140c249551ed1549d21e1eb /libusb/io.c
parent6d037d0625a1e8a68d6bcd0f9f35f9026f97b2bd (diff)
downloadlibusb-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