Comment by ulbu
1 day ago
you need different packed structs for little- and big-endian data. and casting with little-endian data is a nightmare - you need to reverse-cascade your struct fields to be in accordance with the little-endian bit-pattern. (or have a comptime function that does it for you, of course. but then you lose all declarations for the struct). what should be a simple writing down of a protocol is now a pedantic and error-prone ordeal.
Or you just go ahead and forget that big endian ever existed. It's not coming back.
it’s little-endian protocols that require that you juggle your struct fields.
plus, there are still big-endian protocols that will stay for a long time. for example, MIDI clip files in MIDI 2.0 are big-endian.
This has been largely solved by everyone agreeing to use little endian. There aren't really use cases for wanting to convert between them.
Does that mean there are no file formats thatbuse big endian? And network byte order isn't a thing?
if someone chooses to do that they own the problems.
if the network serializes/deserializes for you (kernel primitives) then you don't care what it does. if it doesn't and for some reason you choose to use big endian, again, you own the problem.
8 replies →
Generally those edge cases are always the same endianness. You don't need big and little endianness versions of the structures. What's important is that everyone agrees on the same thing.
1 reply →