On Sun, Sep 5, 2010 at 1:24 PM, Josh Blum <j...@joshknows.com> wrote:
>
>
> On 09/05/2010 04:11 AM, Elvis Dowson wrote:
>>
>> Hi,
>> More specifically, there is a problem with calls to
>> libusb_cpu_to_le16(x) in libusb.h
>>
>> /** \def libusb_cpu_to_le16
>> * \ingroup misc
>> * Convert a 16-bit value from host-endian to little-endian format. On
>> * little endian systems, this function does nothing. On big endian
>> systems,
>> * the bytes are swapped.
>> * \param x the host-endian value to convert
>> * \returns the value in little-endian byte order
>> */
>> #define libusb_cpu_to_le16(x) ({ \
>> union { \
>> uint8_t b8[2]; \
>> uint16_t b16; \
>> } _tmp; \
>> uint16_t _tmp2 = (uint16_t)(x); \
>> _tmp.b8[1] = _tmp2>> 8; \
>> _tmp.b8[0] = _tmp2& 0xff; \
>> _tmp.b16; \
>> })
>>
>
> That seems horrendous, is that even valid c code? Its better defined as a
> function, or maybe a preprocessor conditional byteswap... Is it fixed in the
> libusb10 repo at least?
In libusb, the macro was converted with commit
7ba92cff94bbba19284749c614c26141d3023f37
libusb_cpu_to_le16: macro->static inline function
The error has been reported with Windows and gcc-4.4, which led to the
patch. I'm not sure exactly what caused it to surface in this case.
Oddly enough, the purpose of that macro to begin with was for OSX
support in making "endianness macros endian-independent". Apparently,
cross-compiling issues prevent a preprocessor conditional
implementation.
Elvis, you can either rebuild libusb from git or wait for the v1.0.9
libusb release.
Tom
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
