Add fixed endian types

[lerno]

This tracks the suggestion to add fixed endian types.

[hqnna]

I feel like this would be better as an attribute personally

[flysand7]

I'll write my thoughts here, but won't make any conclusions.

First, this is a convenience feature. Adding it will make it easy to control and reason about endianness. With fixed endian types it is enough to reason about which byte order the value is without caring about flipping the bytes etc. Otherwise you have to think about

• whether the bytes are flipped (usually depending on CPU architecture)
• when the bytes are flipped
• how the bytes are flipped

So, in other words by adding this feature you take away the control from the user, but provide the convenience. The question then arises, when is that important?

The only major use-case for fixed endian is really simple: loading data formats that might come from machines with different architecture. Filesystems define fixed byte order on some fields. Binary file formats do too. TCP/IP protocol suite uses large endian, so even if you limit to x86, there's still need to care about flipping the bytes. Therefore the code that has to deal with fixed-endian data is userspace libraries that deal with file formats, and kernel network/filesystem drivers. As far as I know C3 is a systems-level programming language, so both of these use-cases are relevant.

Since the tradeoff is convenience<->performance, it is possible to add this feature (meaning improve convenience) without losing performance by making sure that compiler optimizations that occur with these fixed-endian types are reasonable. In any case, if compiler's optimizations are not enough the library writer can just get back to using traditional byte swapping routine.

If the library defines a struct with fixed endian type, this can negatively affect performance of the user application. The responsibility for doing so is of course on the library implementer, but since this usage doesn't add anything to performance in this case it might as well be considered useless. As the alternative the library can load a file format an then at the load-time flip the endianness of all the fields (only once!).

So yeah at the end the tradeoff is still convenience<->performance. I'm not sure what C3 should choose here, because C3 seems to have different opinions about whether convenience is important in different places.

[lerno]

One thing to bring in here is also the bitstruct feature. If you do like this:

bitstruct IntBE : int @bigendian
{
  int data : 0..31;
}

Then you have essentially created the big endian type.

The bitstruct is intended to create data format exact structs. I don't know if anyone tried this feature yet...?

[lerno]

Is perhaps the bitstruct a better tool?

[lerno]

Bitstructs are now predefined for BE usage.