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.