[libusb] Possible alignment issues with struct libusb_transfer buffer pointer

[Paul F. <fer...@gm...>]

Hi,

After I tried including libusb.h via an additional local header, I've
stumpled upon a build failure (this is for libusbx HEAD but the same
can be seen with plain libusb):

In file included from libusb_dummy.h:2:0,
                 from libusb1_common.h:25,
                 from libusb1_common.c:26:
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_control_transfer_get_setup':
/usr/local/include/libusb-1.0/libusb.h:1435:9: error: cast increases required alignment of target type [-Werror=cast-align]
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_fill_control_setup':
/usr/local/include/libusb-1.0/libusb.h:1464:39: error: cast increases required alignment of target type [-Werror=cast-align]
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_fill_control_transfer':
/usr/local/include/libusb-1.0/libusb.h:1509:39: error: cast increases required alignment of target type [-Werror=cast-align]
cc1: all warnings being treated as errors

The first line in question:
	return (struct libusb_control_setup *) transfer->buffer;
(the two other are casting to the same struct).

The reason I didn't see it earlier is because gcc normally suppresses
warnings for the "System Headers" but this time it got confused
somehow (gcc version Debian 4.6.2-12). Googling the error message
confirms there're other facing the same issue,
e.g. http://news.gmane.org/group/gmane.comp.ipod.gtkpod/thread=4646
. So this is clearly causing at least some "fails to build from
source" problems.

A quick fix would be to add a (void *) cast to the lines in
question.

But I think here gcc highlights a valid problem that can result in
subtle runtime bugs. If I understand the code right, this pointer
comes from a user-supplied value, and some examples even suggest to
simply declare a char array on stack. struct libusb_control_setup has
some 16-bit fields so they might get misaligned and compiler might end
up generating wrong code to access them on some architectures, this
might end up leading to crashes or silent corruptions.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...