Accounting for endianness

The new WAV loader doesn’t account for endianness. First, is Panda endian-portable? Is it been tested in any big-endian platform? So, should I bother? If so, does Panda have any helper for reversing the common data types like PN_uint16?

EDIT: It seems this is actually a non-issue, as the bytes are going to OpenAL anyway, and OpenAL expects little-ending values even in big-endian platforms.

For the record, Panda is indeed endian-portable, and runs just fine on ppc and arm machines. (It was actually originally developed on a big-endian architecture, the SGI MIPSpro cpu, and ported to Intel’s freak little-endian architecture second.)

The LittleEndian and BigEndian classes are designed as conveniences to convert a word from or into either format, as needed.


Ah thanks, I didn’t find that class for some reason, I guess I forgot to check in dtool/. I’ve just committed support for big-endianness and rdb will test it in arm linux.

And I was wrong in that it wasn’t needed, for the record, although you don’t need to convert the chunks because OpenAL is little endian, you still need to convert things like number of channels and sample rate, which are little endian shorts in the file header.