[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[Stds-754] motion: update exception and flag operations for
provision for writers of library functions, for functions that
are to appear to operate like IEEE primitives.
IEEE primitives signal specific exceptions, and consequently usually
raise specific flags under default handling. What's missing that
library writers need to simulate that?
I was thinking of glue code that encapsulates a runtime's exception
handling. This would save the current flags and modes, set defaults
(which corresponds to traps disabled, summary flags clear), and invoke
the function that produces a result and indicates exception conditions
in the summary flags. On return, the glue code would do what it takes
to pretend the function was a primitive: it will look at the saved
modes and flags (before restoring them), signal those exceptions that
are new and enabled, and merge the summary flags for those that were
not enabled.
Now it is true that this can be done with the restricted primitives
you now suggest, by looking at each flag in turn. If the environment
supports a signal-group operation (not mandatory anymore), the glue
can of course use this, but a portable glue would have to check this.
The preceding may not be a big deal, and perhaps does not justify the
requirement for signal-group operations.
What I really miss in the revised proposal is the paragraph that gives
guidance to the handling of multiple signalled exceptions for the case
where this is supposed to invoke a declared trap handler. I am very
unhappy with the way alternate exception handling is currently defined,
and has been (in various reformulations) for about a year; I don't
remember now if it was the April 2005 or the August 2005 version where
I last saw hope for a sensible resolution.
Why have I not been pro-active in trying to redress what I find so
unsatisfactory? Well, it's because of a much more fundamental issue,
namely the shift from a primitive-oriented view of the 1985 standard
to a language-oriented view of 754R which most of the participants
seem to favour. This is particularly confusing in the context of
exception handling. There is also the fact that multiprocessing
concerns need to be addressed, and the 1985 view is not adequate for
this, so there are indeed no easy answers, and sensible guidelines is
probably the best we can do, certainly given our time constraints.
Michel.
Sent: 2006-08-04 14:45:22 UTC