You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of this moment, the read_f32 and read_f64 methods will bitcast any sequence of 4/8 bytes to a f32/f64 and will never fail, even if the resulting float is a "signaling NaN." In particular, materializing signaling NaNs appear to be undefined behavior, although the topic is pretty cloudy. See rust-lang/rust#39271 for more details.
I think what this means is that these functions need to be modified to return a Result and probably a custom error type as well, although it would be nice to just use the error type that we end up with from rust-lang/rust#39271.
This is a pretty major breaking change, so it will require a 2.0 release.
There is some confusion (at least in my head) around whether signaling NaN's are actually unsafe or not.
The text was updated successfully, but these errors were encountered:
Is it actually a breaking change? I'm not sure a custom error type is needed, just that the returned value would be equal to the NAN constant if sNAN is detected.
@rphmeier That's kind of missing the point though. :-) "Return an error" and "mask the sNaN" are two distinct but valid solutions to this particular problem. Technically, both are breaking changes. The former is obvious since it changes the type signature. The latter is subtle, but if users were previously depending on the specific bit values (say, for serialization purposes), then masking an sNaN will break that behavior. However, if sNaNs provoke undefined behavior (which legitimately seems unknown at this point), then I'm content qualifying it as a bug fix. :-)
See #70 for more details, where I think we decided to just mask the sNaN.
As of this moment, the
read_f32
andread_f64
methods will bitcast any sequence of4
/8
bytes to af32
/f64
and will never fail, even if the resulting float is a "signaling NaN." In particular, materializing signaling NaNs appear to be undefined behavior, although the topic is pretty cloudy. See rust-lang/rust#39271 for more details.I think what this means is that these functions need to be modified to return a
Result
and probably a custom error type as well, although it would be nice to just use the error type that we end up with from rust-lang/rust#39271.This is a pretty major breaking change, so it will require a
2.0
release.There is some confusion (at least in my head) around whether signaling NaN's are actually unsafe or not.
The text was updated successfully, but these errors were encountered: