I called it a hack because it was opaque to me. Why is 0x46464952 generated one way okay and the other way has endianess issues? It's not clear just from an "I said so" answer.Originally Posted by algorism
I called it a hack because it was opaque to me. Why is 0x46464952 generated one way okay and the other way has endianess issues? It's not clear just from an "I said so" answer.
Absolutely. C++ uses const for constants not #define preprocessor macros, however even using const variables you are still likely to want the cast. As Algorism points out the cast is essentially correct. However I don't know what he means by big and little endian problems as WAV is a M$ file format and all M$ operating systems are little endian.
Last edited by Hobbit; 12-03-2016 at 10:53 AM.
I never said or implied "I said so". I honestly thought you understood endianness so therefore didn't consider explaining the technique in detail.
The whole point is that we are not trying to generate 0x46464952 at all. Yes, that's what we want on a little-endian system, which in a sense "reverses" the bytes when it stores them in memory, storing 0x52 ('F') lowest in memory, then 0x49, 0x46, 0x46. But on a big-endian system, the bytes are stored in the opposite order so the hex value must be 0x52494646 to get "RIFF" into memory the way we want.
With the "hack" we put the bytes into memory in the exact order we want them and then interpret them as a 32-bit unsigned integer on the current platform.
