IMATH_NOEXCEPT macro to make noexcept a compile-time option

[cary-ilm]

Legacy code that depends on the IlmBase v2 ExcMath mechanism of signal
handlers that throw exceptions is incompatible with noexcept, since
floating-point overflow and underflow can occur in computations within
Imath functions now marked with noexcept. Legacy code that needs to
accomodate the exception-handling behavior can disable the noexcept
specifier by defining the IMATH_NOEXCEPT macro to be empty. Otherwise,
IMATH_NOEXEPT defaults to "noexcept".

Signed-off-by: Cary Phillips cary@ilm.com

[lgritz]

Excuse the dumb question because I don't use exceptions, so maybe this is just showing off my ignorance.

FPU exceptions don't throw C++ exceptions, do they?

I'm not sure I understand how an overflow leads to a regular C++ exception.

[cary-ilm]

In v2.5, the IexMath library (https://github.com/AcademySoftwareFoundation/openexr/blob/RB-2.5/IlmBase/IexMath/IexMathFpu.cpp) installs signal handlers that catch floating point overflow, underflow, division by zero, and invalid floating point operations, and the signal handlers throw exceptions. ILM also uses a custom "math.h" with fancy macros to substitute throwing versions of sqrt(), etc for the standard library functions. Both of these dramatically affect the normal flow of control and mean exceptions can arise anywhere floating-point computation occurs, which is incompatible with "noexcept".

I'm not necessarily endorsing or encouraging this, but it's behavior a large body of legacy code relies on. It's a philosophy of preventing bad values from ever entering your program's data by intercepting NaN as close to their point of origin as possible.

[lgritz]

I assume that this is was never turned on by default?

[cary-ilm]

It's turned on via the mathExcOn(when) function, which I don't think is invoked by the OpenEXR library, but the Imath python bindings did previously enable them by default.

[cary-ilm]

Added IMATH_USE_NOEXCEPT Cmake option, defaults to ON.