Documentation about endianness support

[Kumar bhat]

What happens if a uint32_t is sent from little endian system and received by bit endian system. For eg: An Ipv4 address. Can we send the IP address in any byte order and be able to see the same value in receiver of a different endian machine? If thats the case, I dont see any documentation for the same. 

[Eric Salo]

An integer sent from one machine to another will preserve its value regardless of the endianness of either machine. If you wish to attach additional semantic meaning to that integer by using it to encode an ipv4 address then you need to take the appropriate steps to translate the local value to and from network byte order, the same as you would for an int32 that was not part of a protobuf.

On Sat, Oct 21, 2023 at 1:48 AM Kumar bhat <urbest...@gmail.com> wrote:

What happens if a uint32_t is sent from little endian system and received by bit endian system. For eg: An Ipv4 address. Can we send the IP address in any byte order and be able to see the same value in receiver of a different endian machine? If thats the case, I dont see any documentation for the same. 

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/e9b8b750-3fe3-4f65-b5ab-4664f791568bn%40googlegroups.com.

[Marc Gravell]

protobuf ensures that the *value of primitives* will be preserved; so if you send the uint32 23433451, it will be decoded as  23433451 regardless of the CPU/process endianness of sender and receiver. The details are here: https://protobuf.dev/programming-guides/encoding/ - but they **don't matter** unless you're writing your own protocol-level tooling.

What the receiver does with that value, however, is up to the receiver. For example, if they interpret that as IPv4 bytes using shift/mask operators: it will be work the same anywhere. If they interpret that as IPv4 bytes using "punning" or any other in-place re-interpret cast: then expect problems. But that's not an issue in the protobuf side - it is an issue in the code that *consumed it*.