What endiannesses do D support?

Brad Roberts braddr at puremagic.com
Fri Oct 4 15:39:21 PDT 2013


On 10/4/13 3:26 PM, Stewart Gordon wrote:
> On 04/10/2013 11:59, Denis Shelomovskij wrote:
>> Some of druntime/phobos code assumes it is one of little/big endianness others have
>> `static assert(0)` for third case. Lets clear the situation and make a decision.
>
> Are you thinking of middle-endian orders such as 2,3,0,1?  Or just wondering in what situations
> neither BigEndian nor LittleEndian would be set?
>
> I suppose that most, if not all, 32+-bit machines are either big-endian or little-endian.  But
> still, I imagine that the "third-case" is just a safeguard in case it is missed when somebody comes
> across a middle-endian platform and tries to compile that code on it.  Or maybe it was just put in
> out of belief that it is a good programming practice.
>
> Endianness support as far as the D language is concerned doesn't seem to be clear-cut.
> http://dlang.org/version.html
> lists LittleEndian and BigEndian, but doesn't state that one of these will always be set.  So
> middle-endian machines, if a D compiler exists for them, would use this "third case".  Further work
> would be needed to determine what particular middle-endian order the machine implements for each
> size of integer.  (Floating points are even more complicated, so I guess you can't rely on any
> version flag to tell you about the format of these.)
>
> OTOH, the platforms on which DMD runs are big-endian or little-endian.  If DMD is ported to a
> middle-endian platform, or the DMD Phobos/druntime code is cribbed for use with a third-party D
> compiler for a middle-endian machine, then the static assert will fire, thereby drawing attention to
> this unimplemented functionality rather than silently generating code that won't work because it's
> written for a little-endian machine, or for a big-endian machine.
>
> Stewart.
>

Good answer.  I'll add only one point:  The use of the else static assert is a good way to catch a 
new platform that's one of little or big but fails to specify.  If the code instead did if (little) 
{...} else {...}, the wrong choice would be potentially made.  Better to require explicitness.


More information about the Digitalmars-d mailing list