LSB/MSB byte order on ppc/linux (powerpc, 32bit)

[konstanty]

LSB/MSB byte order on ppc/linux (powerpc, 32bit)

[manxorist]

I can confirm the issue, on both PowerPC32 (BE) and MIPS32 (BE) with https://modarchive.org/index.php?request=view_by_moduleid&query=108484 .

The root cause here has less to do with the fact that PowerPC is big-endian, but with the fact that libmodplug is writing to const data in at least one of its loaders.

CSoundFile::ReadPSM calls swap_PSMCHUNK(pfh); in line 111, and then bails out in line 121. swap_PSMCHUNK() modifies various header fields starting at offset 0 with bswapLE32() in-place. In CSoundFile::Create(), ReadPSM is tried before ReadMOD or ReadMT2. In MOD, the song title is stored right at the beginning of the file, resulting the the byte-swapped song title getting read.

In the case of MT2, this apparently causes libmodplug to outright misdetect the files as MOD.

The PSM loader leaves the API user provided const file data modified in both, the success and the error path.

I have not reviewed libmodplug thoroughly to determine if there are cases like this in other loaders.

(I'm the libopenmpt maintainer, thus I have also some knowledge about the libmodplug source code.)

[sezero]

Many of the places in libmodplug is little-endian-centric, so it is very much
expected that things fail on big endian hosts.

The PSM loader leaves the API user provided const file data modified

Eww..