www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Strict endianness management where necessary

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
Oct 06 2010