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.
Network byte order has nothing to do with the kernel and you have to care about it
It’s a standard because neither side of the connection knows the endianness of the other side so there must be a standard. That standard is big endian regardless of your architecture or kernel or anything else
So any serialization intended go over the network should be big endian
then you either use an existing C library (the most likely approach) or if you are determined to re-implement it you have to be careful parsing their bytes.
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.
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.
Network byte order has nothing to do with the kernel and you have to care about it
It’s a standard because neither side of the connection knows the endianness of the other side so there must be a standard. That standard is big endian regardless of your architecture or kernel or anything else
So any serialization intended go over the network should be big endian
right, so a zig app will just do little endian. in the very unlikely event you have it running on a big endian machine you have to do extra work.
4 replies →
If someone chooses to load a TIFF or a PSD or an AIFF or…
then you either use an existing C library (the most likely approach) or if you are determined to re-implement it you have to be careful parsing their bytes.
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.
There are some cursed data formats where something is little endian in some places, big endian in other places
Generally speaking though the types you handle in business logic (what your application actually do) shouldn't have any endianness