[llvm-commits] CVS: llvm/include/llvm/Support/MathExtras.h

[Chris Lattner]

On Wed, 17 Aug 2005, Reid Spencer wrote:
>> +// BitsToFloat - This function takes a 32-bit integer and returns the bit
>> +// equivalent float.
>> +inline float BitsToFloat(unsigned Bits) {
>> +  union {
>> +    unsigned I;
>> +    float F;
>> +  } T;
>> +  T.I = Bits;
>> +  return T.F;
>> +}
>
> This one I'm not so sure about. "unsigned" could be 32 or 64-bits
> depending on the platform. float is probably 32-bits on all platforms we
> care about. If unsigned is 64-bits and big-endian, we would get the
> wrong value for the float as it would be effectively shifted into the
> high order bits. Truncation could occur too.
>
> Shouldn't this use uin32_t instead of "unsigned" ?

He's not making things any worse than they were before, but I don't see 
any harm in changing it to uint32_t.  LLVM has many assumptions that 
int/unsigned are 32-bits.  Are you aware of any platform (that matters) 
where int is not 32-bits?

-Chris

>> +// DoubleToBits - This function takes a double and returns the bit
>> +// equivalent 64-bit integer.
>> +inline uint64_t DoubleToBits(double Double) {
>> +  union {
>> +    uint64_t L;
>> +    double D;
>> +  } T;
>> +  T.D = Double;
>> +  return T.L;
>> +}
>
> This should be okay.
>
>> +
>> +// FloatToBits - This function takes a float and returns the bit
>> +// equivalent 32-bit integer.
>> +inline unsigned FloatToBits(float Float) {
>> +  union {
>> +    unsigned I;
>> +    float F;
>> +  } T;
>> +  T.F = Float;
>> +  return T.I;
>> +}
>
> This one suffers same problem as for BitsToFloat
>
> Reid
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/