Hardcode 0/0 => NaN instead of letting C divide 0 by 0

[emanuele6]

In C, division by 0 is unspecified in all cases, so we can't expect a C compiler to always generate code that makes a / b yield NaN if both a and b are 0.

Fixup from 886a9b1

---

Ref: #2253 (comment)

[emanuele6]

I am not sure if this is the right fix, but it at least removes the undefined behaviour keeping the existing intended behaviour.

Do we really want to make 0/0 return NaN instead of throwing an division by 0 error? Why are we making 0/0 return Nan, but 1/0 throw an error instead of returning positive infinity? Do we want to make the arithmetic operators IEEE 754 compliant?

[emanuele6]

Do we really want to make 0/0 return NaN instead of throwing an division by 0 error? Why are we making 0/0 return Nan, but 1/0 throw an error instead of returning positive infinity?

I guess @itchyny made f_divide return NaN for a==0.0 && b==0.0 because constant-folded 0/0 would yield NaN, while 0 | ./0 would throw an error, and wanted to make things more consistent.

Constant-folding considers an error any expression that returns infinity (positive or negative), while f_divide used to only consider expressions with b==0.0 errors; now it considers an error any expression with b==0.0&&a!=0.0 which is still not exactly the same as constant-folding, but it's closer.

Another reason why we should centralise how we do division.