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.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Friday, 4 October 2013 at 10:59:05 UTC, 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.

Little endian and big endian must be supported. Little endian PowerPC, for example, is extremely rare (if not entirely extinct), so just supporting little endian is not enough.

04.10.2013 15:00, Alex Rønne Petersen пишет:
> On Friday, 4 October 2013 at 10:59:05 UTC, 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.
>
> Little endian and big endian must be supported. Little endian PowerPC,
> for example, is extremely rare (if not entirely extinct), so just
> supporting little endian is not enough.

Of course. The question is about "a third case".

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

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.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

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.