4 ms·

Is there a reason why you might want to mix endianness within a file format? Wouldn't it just be extremely error prone as demonstrated in the article?

its_nikita 5y ago
Yeah I was kind of confused about this when I was reading through the spec trying to figure out what went wrong. I wanted to touch on this in the blog post, but I wasn't able to find a good resource explaining the advantage for mixing endianness in a file format.
- cratermoon 5y ago
  Because Microsoft.
  - imoverclocked 5y ago
    Well IBM+Microsoft but really... because 90s and x86.
- AnIdiotOnTheNet 5y ago
  Because the important thing about those fields is that they aren't really big endian at all, they're clearly ASCII characters. Why the spec you have decided to say they were big endian is beyond me.
JonathonW 5y ago
The WAV format is not mixed-endian; everything that’s actually a number is little-endian. The fields the diagram in the article marks as “big endian” are ASCII text— four-byte strings with specific content (“RIFF” for the first ChunkID, “WAVE” for the Format, etc.). If you wanted to treat those as integers in your code, you’d need to treat them as big-endian so their byte order doesn’t get reversed, but they’re really four-byte sequences, not numbers.
- AnIdiotOnTheNet 5y ago
  But they could have just as easily said the integer value for "WAVE" was 0x45564157 in LE and been perfectly consistent.
seoaeu 5y ago
Obviously not ideal, but it could for instance come up when the file format has one overall endianness but wants to include fragments of data conventionally encoded with the opposite endianness. Trivial example would be a .tar file containing an assortment of other files, but this would also include say embedding network endian data or images within a larger file that contains other data.
gizmo686 5y ago
I've had this come up with composite data formats. If your data formats includes already existing data formats and they do not all agree on an endianness you are basically stuck with being inconsistent about it.

its_nikita 5y ago

Yeah I was kind of confused about this when I was reading through the spec trying to figure out what went wrong. I wanted to touch on this in the blog post, but I wasn't able to find a good resource explaining the advantage for mixing endianness in a file format.

cratermoon 5y ago
Because Microsoft.
- imoverclocked 5y ago
  Well IBM+Microsoft but really... because 90s and x86.
AnIdiotOnTheNet 5y ago
Because the important thing about those fields is that they aren't really big endian at all, they're clearly ASCII characters. Why the spec you have decided to say they were big endian is beyond me.

JonathonW 5y ago

The WAV format is not mixed-endian; everything that’s actually a number is little-endian. The fields the diagram in the article marks as “big endian” are ASCII text— four-byte strings with specific content (“RIFF” for the first ChunkID, “WAVE” for the Format, etc.). If you wanted to treat those as integers in your code, you’d need to treat them as big-endian so their byte order doesn’t get reversed, but they’re really four-byte sequences, not numbers.

AnIdiotOnTheNet 5y ago
But they could have just as easily said the integer value for "WAVE" was 0x45564157 in LE and been perfectly consistent.

seoaeu 5y ago

Obviously not ideal, but it could for instance come up when the file format has one overall endianness but wants to include fragments of data conventionally encoded with the opposite endianness. Trivial example would be a .tar file containing an assortment of other files, but this would also include say embedding network endian data or images within a larger file that contains other data.

gizmo686 5y ago

I've had this come up with composite data formats. If your data formats includes already existing data formats and they do not all agree on an endianness you are basically stuck with being inconsistent about it.