Hi, On 06/30/2013 06:15 PM, Paul Fertser wrote: > 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.
Unaligned accesses on architectures which don't support it, either get trapped and emulated (with a fat warnign logged somewhere), or get trapped and terminate the program. So I don't think this may cause "subtle" bugs. I do agree it could happen though. The best way to deal with this is probably to document the alignment requirements and add casts to silence the warning. Notice that actually getting the alignment wrong is pretty hard, most ABI's guarantee some stack pointer alignment when entering a function, so having an unaligned buffer would require declaring vars like ie this: unsigned char unalign[3]; unsigned char buffer[16]; But you're right, this might be a real issue. Unfortunately I don't see any better solution then documenting the alignment requirements. I have considered doing an assert on unaligned buffers, but that would break code which works today, since most arch0-s either support or emulate unaligned accesses. Since you're actually getting the warnings can you provide a patch to silence them ? Thanks & Regards, Hans ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
