• bearophile (15/16) Oct 06 2010 Linux Kernel defines the types __le16, __le32, __le64, __be16, __be32, a...

bearophile <bearophileHUGS lycos.com> writes:

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