Re: [Libusbx-devel] Improved logging v2
2013/6/27 Tim Roberts : > Hans de Goede wrote: >> You're right, and I'm sorry. I guess I'm to much of a rero person sometimes. >> >> Although win32 is far from my specialty I think the attach patch should fix >> it. Any chance you could give it a try? > > This is micro-optimization, of course, but it would be more efficient to > do this instead: > fputs(str, stderr); I also agree. Maybe Pete missed your email. Attached is the commit for this change. Bye -- Dr. Ludovic Rousseau 0001-Core-use-fputs-3-instead-of-fprintf-3.patch Description: Binary data -- 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
Re: [Libusbx-devel] Improved logging v2
On Sun, Jun 30, 2013 at 7:45 AM, Pete Batard wrote: > https://github.com/libusbx/libusbx/commit/7b893cc7cee185c0bf771166ca61a05b32800556 > should now fix the cywgin issue, as well as sort our gettimeofday() > usage for all the Windows compilers. It also includes the missing "%s" > reported earlier. > > The issue really was that __GCC__ never existed in the first place, even > for MinGW, and we should have used __GNUC__ all along instead. > > I tested compilation for all of MSVC/WDK/MinGW(32/64/Clang)/cywgin and > everything looks good now. Great. I just tried under Mac OS X and Windows 7 x86 (WDK, Cygwin, MinGW and MinGW-w64 32bit) and all are fine. > While I was at it, I increased the buffer size to 1024 (we have some > crazy long strings for the USB ids on Windows, and I feel that 256 bytes > might be two small if we ever try to print 2 of them), and fixed some > whitespace/quotes issues that had been bothering me. > > > Once more, given the amount of changes that have been pushed since RC1, > I would strongly suggest that we declare RC2 and push the 1.0.16 > milestone (due tomorrow [1]) by one week (which may give us a chance to > sort out #95 [2] that is still open against 1.0.16). I agree to have RC2 and push 1.0.16 release later by one week. As for issue #95, it is not that important, so either to fix it or delay it is okay with me. > > [1] https://github.com/libusbx/libusbx/issues/milestones > [2] https://github.com/libusbx/libusbx/issues/95 -- Xiaofan -- 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
Re: [Libusbx-devel] Improved logging v2
On Sun, Jun 30, 2013 at 4:28 PM, Xiaofan Chen wrote: > On Sun, Jun 30, 2013 at 7:45 AM, Pete Batard wrote: >> Once more, given the amount of changes that have been pushed since RC1, >> I would strongly suggest that we declare RC2 and push the 1.0.16 >> milestone (due tomorrow [1]) by one week (which may give us a chance to >> sort out #95 [2] that is still open against 1.0.16). > > I agree to have RC2 and push 1.0.16 release later by one week. Milestones updated. > As for issue #95, it is not that important, so either to fix it > or delay it is okay with me. >> >> [1] https://github.com/libusbx/libusbx/issues/milestones >> [2] https://github.com/libusbx/libusbx/issues/95 -- Xiaofan -- 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
[Libusbx-devel] Possible alignment issues with struct libusb_transfer buffer pointer
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:fercer...@gmail.com -- 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
Re: [Libusbx-devel] Improved logging v2
On 2013.06.30 08:58, Ludovic Rousseau wrote: > 2013/6/27 Tim Roberts : >> This is micro-optimization, of course, but it would be more efficient to >> do this instead: >> fputs(str, stderr); > > I also agree. Maybe Pete missed your email. Oops, my bad. Apologies to Tim for missing his mail, and thanks to Ludovic for the patch. While I'd expect most compilers to be smart enough to make these kind of optimizations, I have now applied and pushed it, under Tim's name, since he's the one who proposed the change. Regards, /Pete -- 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
