On Wed, 2013-07-31 at 14:58 +0200, David Henningsson wrote: > On 07/30/2013 02:49 PM, Arun Raghavan wrote: > > On Tue, 2013-07-30 at 14:29 +0200, Peter Meerwald wrote: > >> > >>> Improves correctness, unbreaks software volume in recent Android. > >>> --- > >>> src/pulse/sample.h | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/src/pulse/sample.h b/src/pulse/sample.h > >>> index 9eb4df0..34087e0 100644 > >>> --- a/src/pulse/sample.h > >>> +++ b/src/pulse/sample.h > >>> @@ -120,7 +120,7 @@ PA_C_DECL_BEGIN > >>> #endif > >>> > >>> /* On Sparc, WORDS_BIGENDIAN needs to be set if _BIG_ENDIAN is defined. */ > >>> -#ifdef _BIG_ENDIAN > >>> +#if defined(__sparc__) && defined(_BIG_ENDIAN) > >>> #define WORDS_BIGENDIAN > >>> #endif > >> > >> this potentially breaks other big endian platforms? PPC/MIPS maybe? > > > > Pretty sure it won't. That bit of code was added in 4.0 specifically to > > deal with Sparc. > > > >> are there big-endian Android devices? who sets this? why? > > > > There aren't, but they seem to be defining _BIG_ENDIAN in their headers > > for some reason. > > > > I tried to review this one, and came across this code: > > http://devel.kamailio.org/sr-svn/trunk/test/endian_test.c > > It looks like some headers define both _BIG_ENDIAN and _LITTLE_ENDIAN > (perhaps one is defined as "1" and the other as "0"?), so maybe a > > #if defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN) > > ...could be an option here? I prefer the arch-specific way since that's what this condition was added for, and only try to fix endianness detection elsewhere if it is found to be broken. -- Arun
