I ask this question here because the creators of Transport probably had to do with this and may have knowledge about it. The knowledge about this subject I was able to find on the Internet is quite vague.
I am implementing my own serializer and I plan to always serialize data as little endian. So I will need to swap bytes on big endian platforms.
Int and long are obvious, but my question is about float and double. Are the rules the same as for int and long? Do I just need to swap all bytes and that’s it? Is it like that on all platforms supported by Unity?
I have checked the source code of DataStreamWriter and DataStreamReader and they use the same swap for float and int, so that would confirm that it is enough.
It’s generally safe to assume the endianness of floating point types to be the same as for integer types. So you can use the same byte swapping operations as you would use for integer types of the same length. Technically there are CPUs out there using one endianness for integers and another for floating point values, but they’re mostly older and esoteric architectures. Not something one should worry about when working with Unity.
In fact, if you’re only concerned with platforms Unity supports, you can probably safely assume everything is little endian. I don’t believe any of our supported platforms are big endian.
No WebGL game made with Unity will run on big endian machines, because Emscripten (which Unity uses to compile its runtime to the web platform) does not support big endian hosts. And even then you’d be hard-pressed to find a big endian machine that can run a modern browser anyway.
Sounds like it is not worth bothering at all to check for the endianness. DataStreamWriter and Reader probably are checking just in case. I would add the check too, but my serializer is able to serialize a whole unmanaged structure at once. So to properly swap bytes of every field of the structure I would probably have to use Reflection, which would be slow. And according to what you said (and the link you provided) will most likely never be needed and implementing it will probably be a waste of time. So I will not do this.