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 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 > > I'd vote for Hans' approach of returning both codes. The point of the > function is to convert an error code int to error code string. While > LIBUSB_SUCCESS and LIBUSB_TRANSFER_COMPLETED are such an error code > (albeit error codes that indicates that there wasn't any error), > "NO_ERROR" isn't. > > I think we may want to do something with regards to >0 codes however, as > some people may use libusb_error_name on transfer type calls, that > return a positive number on success and a negative error code on error.
Ah, such as libusb_control_transfer() I assume, hmm, good point. Well before my patch those would return "**UNKNOWN**", and know if the amount transfered is small enough they may return a "LIBUSB_TRANSFER_FOO" string. Which brings us to Peter's point that it may be better to have 2 functions for this. I'm not sure what is best, but I tend towards keeping a single function for this: 1) Making this 2 functions will probably only lead to people using the wrong one occasionally (I did so in my own code, and I think it is safe to say I know the difference). And it means we will also need 2 variants of libusb_strerror, so we end up with 4 instead of 2 functions for this. 2) People should simply not call error_name when there is no error, so the problem is purely theoretical. We could (and should) document that they should not do that, and leave things at that. So I propose to amend the patch to document that error_name should only be called in case of error, and that the behavior is undefined when called on success results. Regards, Hans ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
