From: John Maddock (john_at_[hidden])
Date: 2007-06-30 04:29:08
Ulrich Eckhardt wrote:
> Hi!
>
> This is basically the result of a discussion on the STLport
> mailinglist. The question came up what this code means:
>
> #if defined(_BIG_ENDIAN)
> 0x7f80 << (sizeof(int)*CHAR_BIT-16),
> #else
> 0x7f800000,
> #endif
>
> This is from detail/limits.hpp. The puzzling thing is that the result
> for big-endian targets is exactly the same, unless the size of an int
> is not 32 bit, but the size of the int has nothing to do with
> endianess still...
>
> I dug around a bit, and it was added some time ago by John Maddock
> with the comment that it adds support for big-endian SPARC machines,
> but later also used for big-endian MIPS and PPC. There also used to
> be a comment saying something like: "making this depend on big-endian
> targets is wrong, it's the layout of floats we care about, not the
> layout of integers when written to memory". This comment was removed
> when the ad-hoc endian detection was replaced with the centralized
> one.
>
> Can anybody see what this code is supposed to do? I understand that
> 0x7f800000 is an integer with the same bit layout as one of the
> special floating point constants, but I can't figure out why it would
> be any different on big-endian machines.
OK, first off I've never had access to sparc machines, so I would have been
applying a patch that someone else had submitted, unfortunately I can't
locate the original message at present :-(
The reason for there being a difference on *some* big-endian machines is
that while the byte order of int's has swapped around, floats retain the
same IEEE-specified order. But, that implies this code does indeed look
wrong!
However, this code was only ever used for gcc-2.95 if I remember correctly,
so it's effectly depricated fluff these days...
Not sure if this helps, John.