Yeah it's an interesting case. It appears that Inf is in floating point to AVOID a trapped error.
This answer has an interesting way of looking at it. If you go on the theory that floating points are supposed to represent reals, then in floating point, you can't tell if a value is actually zero or just indistinguishably close to zero.
In the case of "indistinguishably close to zero", you're getting the wrong answer, and the program doesn't halt. It keeps on chugging doing bad math. So that's an untrapped error, and it's UNSAFE by Cardelli's definition.
Floats aren’t reals, at best they are an approximation for certain calculations. +0 and -0 are defined and distinct floating point numbers. Floating point math is known to be problematic and does not evenly distribute numbers on the real line either. There are numerical methods used for reducing error on floating point operations when it is acceptable. Otherwise fixed point or intervals may be used.
This answer has an interesting way of looking at it. If you go on the theory that floating points are supposed to represent reals, then in floating point, you can't tell if a value is actually zero or just indistinguishably close to zero.
In the case of "indistinguishably close to zero", you're getting the wrong answer, and the program doesn't halt. It keeps on chugging doing bad math. So that's an untrapped error, and it's UNSAFE by Cardelli's definition.
https://cs.stackexchange.com/questions/82811/why-do-floating...
The key point is that "safe" sometimes means "crashes" and sometimes means "doesn't crash". It's an auto-antonym in that sense.
A broader definition is "errors are flagged as early as possible", including with seg faults / hardware exceptions.