# [std-interval] More on interval computations as proofs

Steve Clamage Stephen.Clamage at Sun.COM
Sat Sep 30 15:44:56 PDT 2006

```About errno, ignoring threading issues:

Errno can be set to any value (including 0) by any function.

Consider the expression Gaby posted:
c = f(h() + i(), y());
The order of evaluation of h(), i(), and y() is unspecified. The +
operation could be computed before or after y(). ("Unspecified" means
that the order need not be documented or even consistent.)

Errno could be set by any operation in the sequence, including by the
standard math functions underlying interval calculations.

If you rely on errno, you have to be sure it is 0 before this statement
to avoid a false positive. If you check it again after the statement and
find it is non-zero, you have no way to tell what went wrong or where.
You see only the last value assigned to it, and you don't know the order
of operations.

Now suppose errno is 0 after the statement. If one of the sub-operations
also depended on errno, it might have set errno to 0, wiping out a
previous error indication.

To use errno effectively, across each micro-operation you must save it,
set it to zero, check after the operation, and decide what to do if it
is now non-zero but with a different non-zero value than before. Apart
from making the source code unreadable and unmaintainable, the large
number of conditionals kills performance.

Using errno as a reliable and general-purpose error indicator is not
realistic.

The idea behind C++ exceptions is that you can write mainline code that
assumes everything is OK. If something does go wrong, you throw an
exception that can be caught at a place in the code where you are
prepared to deal with it. You don't need to check every operation. C++
implementations often have no runtime overhead when exceptions are not
actually thrown. (There will be space overhead.)

Throwing and catching a C++ exception is generally expensive. The design
guideline was to use exceptions for "exceptional" conditions, not for
ordinary control flow, so that the overhead will not have an important
effect on overall performance.

If you want accurate error detection and propagation, the alternative to
exceptions is to pass around a status variable. Which one is the better
choice depends the program or library design details.

---
Steve Clamage, stephen.clamage at sun.com
```