vlovich/hidapi — comment on commit dc6ca22775e4a8d9249b710a1a86b6df0050f569
File:  line 0
By signal11:

I'm not sure I like the memory allocation on hid_write() for several reasons. The first reason is that it is a bug in the application to pass in a buffer for a report which is shorter than the report you are trying to send (ie: passing in 8 bytes for a 16 byte report). Indeed one can get away from it on other platforms, but it is a logic error in the application nonetheless. With your solution, if the user passes in a short buffer, it will work, but silently be inefficient, having to do a malloc() and then a free() for every hid_write(). I think that's less than desirable. This could be averted by making the temporary buffer part of the hid_device struct, but then synchronization would have to be done on writes, again, a silent performance penalty.

My opinion is that the user needs to know what data the device they are sending data to wants, and they need to send that data to the device as the device wants and expects it. I am willing to be convinced otherwise though if you have a good reason for it.

For your read buffer, it's not synchronized. Two threads will clobber one another if they both call hid_read() at the same time. HIDAPI is for the most part thread safe, at least for the runtime functions (read/write/feature). I have not done a full audit of all the threading issues on all platforms, and there may be other threading issues, but I'd rather not introduce something that I know to be non-threadsafe.

Again, what is the goal here? You want hid_read() to partially function if the user passes in a buffer that's too small for the reports they are expecting? Is it not better for it to fail than for it to silently return only a partial report?

Alan.