IEEE 754-2008 or IEEE 754-1985?

[est31]

Currently the reference says:

The IEEE 754-2008 binary32 and binary64 floating-point types: f32 and f64, respectively.

Now is it legal per the reference to port Rust to to platforms that don't implement IEEE 754-2008 but only IEEE 754-1985, and which can deviate in their floating implementation from IEEE 754-2008? Some MIPS platforms come to my mind that implement signaling NaNs differently.

[est31]

For context:

• IEEE 754-1985 says that "Signaling NaNs shall be reserved operands" but it doesn't specify what their representation is. Only IEEE 754-2008 does it.
• According to this comment by @sunfishcode , one can make MIPS conform to the NaN behaviour specified in IEEE 754-2008. Does Rust set this register currently? Does that make MIPS fully conformant to IEEE 754-2008?
• Some other useful links: https://en.wikipedia.org/wiki/NaN#Encoding and https://www.math.utah.edu/~beebe/software/ieee/README.NaN

Maybe I should have filed on rust-lang/rust instead. But I'd prefer if the documentation was adjusted to IEEE 754-1985 than if Rust declared to be non portable to MIPS (and similar CPUs that don't implement IEEE 754-2008 either but implement IEEE 754-1985).

[est31]

Another interesting link (also about MIPS, not talking about the other CPUs): https://dmz-portal.imgtec.com/wiki/MIPS_ABI_-_NaN_Interlinking

[sunfishcode]

IEEE 754-2008's sNaN encoding is a "should", not a "shall", so there's no hard requirement. I encourage Rust to reference the 2008 spec (and the 2018 spec once it's finalized).

[Havvy]

As I see no definitive proof that Rust is not a priori portable to MIPs nor that MIPs cannot impl the 2008 spec, and that the constexpr float libraries impl the 2008 spec, I don't think there's anything to actually change here?

I think the best place for these kinds of questions would be IRC, or on the internals forum should you want it on a linkable record or nobody is answering.