digitalmars.D - Strict endianness management where necessary
- bearophile (15/16) Oct 06 2010 Linux Kernel defines the types __le16, __le32, __le64, __be16, __be32, a...
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