On Monday 05 January 2009 17:36:57 ext Brad Midgley wrote: > Siarhei > > > SBC encoder contains the following fragment: > >> #if __BYTE_ORDER == __LITTLE_ENDIAN > >> if (sbc->endian == SBC_BE) > >> #elif __BYTE_ORDER == __BIG_ENDIAN > >> if (sbc->endian == SBC_LE) > >> #else > >> #error "Unknown byte order" > >> #endif > >> s = (ptr[0] & 0xff) << 8 | (ptr[1] & > >> 0xff); else > >> s = (ptr[0] & 0xff) | (ptr[1] & 0xff) << > >> 8; > > > > This does not look right. Because as far as I can see, it will work > > differently on big and little endian systems > > I tested it some time ago on powerpc and I know Marcel also has a > powerpc for testing. I'll need to update my machine for bluez 4.x. > > The logic here seems to be to swap bytes if the endian set in the sbc > struct does not match host endian. The logic is that the first line contains a portable endian neutral read of big endian data into native format: > s = (ptr[0] & 0xff) << 8 | (ptr[1] & 0xff); The second line contains a portable endian neutral read of little endian data into native format: > s = (ptr[0] & 0xff) | (ptr[1] & 0xff) <<8; If __BYTE_ORDER is defined as __LITTLE_ENDIAN, the first line is used when sbc->endian == SBC_BE. But if __BYTE_ORDER is set to __BIG_ENDIAN, the logic is reversed. The behaviour and the end result seems to be different for the big endian and little endian systems. This can be probably easily tested by encoding the same file by sbcenc on big and little endian systems and comparing results. -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
