804924 - Add some NaN checks in Graphics

Status: NEW

(Core :: Graphics, enhancement)

Description

[Jesse Ruderman]

Attachment: Checks I scattered locally while debugging bug 803949

Bug 803949 took me a while to track down because a NaN value had propagated a long way before causing a crash.  And because I'm bad at using MSVC.

Are there some pinch points or API boundaries where it would make sense to have MOZ_DOUBLE_IS_FINITE or !MOZ_DOUBLE_IS_NaN checks?

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

In _general_ asserting that matrices are non-singular (which is the same as asserting that the inverse is finite) is a bad idea, because it is generally hard or impossible to guarantee that this will never happen.

In _special_ cases however that can be OK, typically in cases where one can prove that the number can't possibly be non-finite unless a bug occurred.

Look at it this way: if we wanted to assert on NaN, a much better, easier, reliable way to do that would be to simply turn on FP signaling. My claim here is that if we did, we'd cause strange, hard-to-reproduce bugs for users. The reason why almost nobody does is that it's indeed generally a better idea to design FP code to be resilient to non-finite values and handle them gracefully. For example, if a graphics transformation matrix is singular, drawing should simply be a no-op.

Comment 0 says that a NaN value had somehow caused a crash. The first problem here, then, is that some code relied on a value to be finite in order to not crash. That's the real problem here. It's never OK for any code to crash if some input float is NaN.