more on trapping in C

[David G. Hough at validgh]

Responding to some points raised by Alan McKenney:

> 	The trend appears to be towards *not* trapping (whether
> 	to abort or otherwise) on an exception, and to provide
> 	*no* facility to do so, either.  I consider this a step
> 	*backwards.*

And indeed *no* facility to enable trapping would be a step backward
from having such a facility, although I'm not aware of any products
that removed such a facility.    Fully satisfactory exception handling
is rather complicated and has lots of system ramifications, so a few
implementations first would normally be considered necessary prior to
standardization.

>     generate floating-point exceptions.  However, since 99% of
>     all exceptions are due to bugs, and moreover all
>     floating-point hardware that I know of provides this
>     facility, it seems strange to ignore exceptions.

A good IEEE 754 implementation provides retrospective diagnostics to insure
that exceptions are not ignored.    I was able to do that for the Sun
Fortran run-time system many years ago, but not for C, because Fortran
basically was built on top of C.

>     No one
>     would propose ignoring fetches from non-existent memory (what
>     Unix calls "segmentation violation".)

Some architectures provide non-faulting loads for prefetching data into
caches prior to knowing whether it will be used.    If it won't be used,
the exception doesn't matter.

>     However, I believe it was here that I read that interval methods are
>     still only useful to a small class of problems.

Interval methods are quite an active research area, with increasing numbers
of successes, and I am hopeful for
better software and hardware support in the future.

>     Does Sun consider the specification of the ieee_* calls proprietary?

Sun generally favors open interfaces and proprietary implementations, so I
doubt there would be a problem if somebody implemented the same interfaces
elsewhere.     Consult all relevant legal departments before taking action,
of course.    Though some of my colleagues disagree,
I personally don't care for the ieee_flags and ieee_handler
character interfaces; they are not very C-like; I prefer the style of
NCEG's interfaces corresponding to ieee_flags.

>     I don't understand your distinction between a "trap" and a "signal."
>     The issue is: what happens when your program, e.g., divides by
>     zero: continue, crash, or call a subroutine.  Unix calls this
>     a signal.  Other people refer to this as a trap.

"IEEE 754 traps" are generally supposed to correspond roughly
to C/Unix signals, but
the latter cover a much wider range of events,
and don't usually provide all the information to signal handlers that
IEEE 754 requests,
and what is provided is necessarily in a machine-dependent format.

Confounding the nomenclature are hardware traps that may or may not be 
visible in user mode.    For instance, in some SPARC implementations,
there may be hardware "traps" for all subnormal and invalid operands and 
results, but these are handled in the kernel software without causing user-level
signals unless the relevant IEEE 754 trap-enable bits are on in the 
floating-point control/status register.