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?

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.