Is it safe to reinterpret_cast an integer to float?

Question

Note: I mistakenly asked about static_cast originally; this is why the top answer mentions static_cast at first.

I have some binary files w

Answer 1

Well, static_cast is "safe" and it has defined behavior, but this is probably not what you need. Converting an integral value to float type will simply attempt to represent the same integral value in the target floating-point type. I.e. 5 of type int will turn into 5.0 of type float (assuming it is representable precisely).

What you seem to be doing is building the object representation of float value in a piece of memory declared as Uint32 variable. To produce the resultant float value you need to reinterpret that memory. This would be achieved by reinterpret_cast

assert(sizeof(float) == sizeof val);
return reinterpret_cast<float &>( val );

or, if you prefer, a pointer version of the same thing

assert(sizeof(float) == sizeof val);
return *reinterpret_cast<float *>( &val );

Although this sort of type-punning is not guaranteed to work in a compiler that follows strict-aliasing semantics. Another approach would be to do this

float f;

assert(sizeof f == sizeof val);
memcpy(&f, &val, sizeof f);

return f;

Or you might be able to use the well-known union hack to implement memory reinterpretation. This is formally illegal in C++ (undefined behavior), meaning that this method can only be used with certain implementations that support it as an extension

assert(sizeof(float) == sizeof(Uint32));

union {
  Uint32 val; 
  float f;
} u = { val };

return u.f;

Answer 2

In short, it's incorrect. You are casting an integer to a float, and it will be interpreted by the compiler as an integer at the time. The union solution presented above works.

Another way to do the same sort of thing as the union is would be to use this:

return *reinterpret_cast<float*>( &val );

It is equally safe/unsafe as the union solution above, and I would definitely recommend an assert to make sure float is the same size as int.

I would also warn that there ARE floating point formats that are not IEEE-754 or IEEE-854 compatible (these two standards have the same format for float numbers, I'm not entirely sure what the detail difference is, to be honest). So, if you have a computer that uses a different floating point format, it would fall over. I'm not sure if there is any way to check that, aside from perhaps having a canned set of bytes stored away somewhere, along with the expected values in float, then convert the values and see if it comes up "right".