[Libreoffice-commits] core.git: sc/qa

[Eike Rathke]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150813/f3543f62/attachment.sig>