Hacker News new | ask | show | jobs
by charcircuit 2 hours ago
This has been largely solved by everyone agreeing to use little endian. There aren't really use cases for wanting to convert between them.
2 comments

yea, well, tell the industry to solve it, too. MIDI 2.0, for example, is little-endian, but big-endian for its clip files and sysex. MIDI 1.0 sysex is also big-endian. ie, the entire music industry rests on a protocol that has a sizeable chunk of big-endian.

and I did not say about conversion between the two. I said that there are protocols that are big-endian and that to deal with them, zig leaves too much to the programmer to fiddle in. (unless I misconstrue the focus of your comment)

Does that mean there are no file formats thatbuse big endian? And network byte order isn't a thing?

    > there are no file formats thatbuse big endian
if someone chooses to do that they own the problems.

    > network byte order isn't a thing
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.
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.