Endianness

[pepone]

https://docs.testing.zeroc.com/docs/slice/encoding/main-features#little-endian

On the other hand, the ice and icerpc protocols define their frame headers and control frames using Slice; this usage favors big-endian ordering.

We selected little-endian because Slice's main job is to encode/decode the payloads of requests and responses. Its use for the ice and icerpc frame headers is secondary. And it's simpler to use the same ordering (little-endian) in all situations.

What does it mean that it favors big-endian? To me, this sounds a bit like using big-endian for the protocol would be better, but we use little-endian because it is simpler to always use the same, which I don't think is the case.

[bernardnormier]

The answer is in the sentence above:

All modern CPUs are little-endian, while the standard endianness for network protocols is big-endian.

From https://en.wikipedia.org/wiki/Endianness:

Big-endianness is the dominant ordering in networking protocols, such as in the Internet protocol suite, where it is referred to as network order, transmitting the most significant byte first. Conversely, little-endianness is the dominant ordering for processor architectures (x86, most ARM implementations, base RISC-V implementations) and their associated memory. File formats can use either ordering; some formats use a mixture of both or contain an indicator of which ordering is used throughout the file.

To me, this sounds a bit like using big-endian for the protocol would be better,

Yes, it would better to use "network order" aka big endian for the protocol headers. That's the endianness you expect in protocol headers. E.g. the original Google QUIC was little-endian; the standardization process quickly switched to big-endian.

but we use little-endian because it is simpler to always use the same,

Yes, that's the case.

which I don't think is the case.

It is.

[pepone]

I think better to remove the last two parragraphs

On the other hand, the ice and icerpc protocols define their frame headers and control frames using Slice; this usage favors big-endian ordering.

We selected little-endian because Slice's main job is to encode/decode the payloads of requests and responses. Its use for the ice and icerpc frame headers is secondary. And it's simpler to use the same ordering (little-endian) in all situations.

Before this, we already make clear that Slice encoding always uses little-endian.

I think this is not the page to go into details about ice/icerpc protocol headers endianness. The page is supposed to be about the main features of the Slice encoding.

[bernardnormier]

I think better to remove the last two parragraphs

On the other hand, the ice and icerpc protocols define their frame headers and control frames using Slice; this usage favors big-endian ordering.

We selected little-endian because Slice's main job is to encode/decode the payloads of requests and responses. Its use for the ice and icerpc frame headers is secondary. And it's simpler to use the same ordering (little-endian) in all situations.

Before this, we already make clear that Slice encoding always uses little-endian.

Where? I don't see it. The conclusion "We selected little-endian" is in the last paragraph.

I think this is not the page to go into details about ice/icerpc protocol headers endianness. The page is supposed to be about the main features of the Slice encoding.

As I explain on this page, the choice is not obvious:

• CPU-wise and payload-encoding wise, little-endian is the best choice
• protocol-header wise, big-endian would be the best choice

I am not going into any details here, just explaining briefly the situation.

[pepone]

We can keep as is if you think it is relevant, to me it gives the impression that "icerpc" protocol would be better using big-endian.

I don't think there would be any real improvement here, other than following a convention of protocol headers.

To me, it would be enough to mention that Slice always uses little-endian, and that we choose that because all modern CPU are little-endian.