Strict endianness management where necessary

[bearophile]

Linux Kernel defines the types __le16, __le32, __le64, __be16, __be32, and __be64 used by the Sparse tool, they are like the old D typedefs of little-endian and big-endian unsigned values of 16, 32 and 64 bits.

See:
http://lwn.net/Articles/205624/

>For most programming, even within the kernel, endianness is not a concern; things just work without much thought on the programmer's part. Kernel code often must work with data encoded in a specific byte ordering which might not match the processor's ordering, though. Network protocols, filesystem on-disk data structures, and device registers are all examples. In general, when the kernel works with data in a non-native ordering, it must first swap the bytes around to match the processor's expectations. Failure to do so can lead to all kinds of strange bugs.<

For example, __le32 and __be are widely used:
http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=__le32
http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=__be32


For this purpose a special Phobos module (or Object) may add six similar typedefs, they may be named:
__leushort __leuint __leulong  __beushort __beuint __beulong
Or just as the Linux ones:
__le16, __le32, __le64, __be16, __be32, and __be64

I have not filed an enhancement request about this because I don't personally need this feature and because I am not sure D2 is designed to write kernels/device drivers anyway.


About endianess matters I have recently added a note at the bottom of the request for enhancements for bitfields:
http://d.puremagic.com/issues/show_bug.cgi?id=4425

Bye,
bearophile