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. Uli
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.
On Saturday 30 June 2007 10:29:08 John Maddock wrote:
Ulrich Eckhardt wrote: [...]
#if defined(_BIG_ENDIAN) 0x7f80 << (sizeof(int)*CHAR_BIT-16), #else 0x7f800000, #endif [...] 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!
Okay. I'm not even really sure what the code does in general, maybe some of the STLport people that initially stumbled across it can determine what it's supposed to do and then add according unittests. If this had some cryptic meaning, those should unveil it...
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.
It does! Uli
participants (2)
-
John Maddock -
Ulrich Eckhardt