[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


More information about the Std-interval mailing list