Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.