From: Pete B. <pb...@gm...> - 2010-08-13 11:23:54
|
On 2010.08.13 04:48, Daniel Drake wrote: > I'm thinking of committing this plus doxygen docs for the macro, but > with the macro named as LIBUSB_CC (CC = calling convention). Any > thoughts on that? I'm fine with this change, as I agree it'll make the purpose of that macro clearer. I'm sending an updated version of patch #1 that takes that change into account, and that fixes another issue as I found out that dpfp/dpfp_threaded had been left out of my initial patch. I'm expecting the change will introduce conflicts in git for subsequent patches, so I'll redo & resubmit those as well, after people have had a chance to comment on the calling convention. As to doxygen, I'd rather leave you do it. One important element you might want to point out is that, for Windows or cross plastform code, callback declarations require an explicit mention of the calling convention. For instance, in dpfp.c we must now use: static void LIBUSB_CC cb_mode_changed(struct libusb_transfer *transfer) to conform to the following from libusb.h: typedef void (LIBUSB_CC *libusb_transfer_cb_fn)(struct libusb_transfer *transfer); And it looks like there's no escaping the explicit LIBUSB_CC, as the following is not accepted by compilers: libusb_transfer_cb_fn cb_mode_changed(struct libusb_transfer *transfer) The reason we need the calling convention on callbacks is that a shared libusb DLL might could otherwise try to access callbacks using its default calling convention, which might be different from the one used by the app. Regards, /Pete |