Hi, On Thursday, 2015-08-13 11:36:11 +0200, Stephan Bergmann wrote:
...or, developers be taught about the C++ Standard? ;) It is quite clear on this: "If the second operand of / or % is zero the behavior is undefined." ([expr.mul]/4)
Lame excuses of a standards committee not being able to agree on something or force anyone to change implementation ;-)
Now, ISO/IEC 60559 may mandate the result of division by zero to be infinity under certain circumstances (if the dividend is finite and non-zero) an NaN otherwise, when operating in its default exception handling mode, and C++ implementations may follow that, and we may even require that at least certain parts of the LO code base must be executed in conformance to ISO/IEC 60559 in its default exception handling mode.
Calc gracefully handles infinity and NaN in the interpreter (well, as long as the compiler/hardware for such operations actually generates either and doesn't decide to return 0 instead because it's undefined ;) and in intermediate or final results sets an error if detected. We don't strive to handle +-infinity and NaN in further calculations, but we detect them as error condition.
However, in other parts of the LO code base it might be unexpected that floating-point division by zero happens, and its occurrence might indicate a bug (cf. "git log --grep -fsanitize=float-divide-by-zero"), so I'm reluctant to disable -fsanitize=float-divide-by-zero wholesale.
Agreed.
For those places where we apparently require floating-point division to adhere to ISO/IEC 60559 in its default exception handling mode, would it be possible to "dress those up" (like in the below ad-hoc patch), or would that be unreasonable?
We already have ScInterpreter::div() that uses sc::div() from sc/inc/math.hxx creating a NaN with a div/0 error value bit pattern for x/0, I'll merge the 0/0 part of your patch to flag the different condition, thanks for the detail. Using that in the place in question though will make it necessary to adapt the unit test, which maybe shouldn't rely on the exact error value anyway. Maybe we should even just bail out early if /0 occurs. I'll take a look. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
pgpNmwCiOK2en.pgp
Description: PGP signature