Mail Archives: djgpp-workers/2003/08/29/18:00:53
Richard Dawe wrote:
>ams AT ludd DOT luth DOT se wrote:
>
>
>>For me raise an exception == generate a signal. Both Eli and you
>>seems to say that raising an exception is something else than
>>generating a signal.
>>
>>Can somebody explain this to me?
>>
>>
>I think you're confusing the word "exception" in maths terms with "exceptions"
>represented by SIG*. In the case of the maths "exceptions" I think the
>exception is signalled by setting a bit in some exception register somewhere.
>See section 7.6.1 (FE_* constants like FE_INVALID) and section 7.6.2 of the
>C99 standard.
>
>(That's from a quick read of the sections mentioned. I may be wrong.)
>
>
I have posted a question to comp.std.c where I've asked what
"floating-point exception" means in terms of the standard, among other
things. It appears to me that the committee members had in their minds
something like the exception bits in the floating-point status word of
the x87, but of course they can't say that in the standard; one has to
access the bits through standard C functions and variables.
I've also asked comp.std.c how we can have "floating-point exceptions"
required in Annex F for math functions when, as I noted earlier, the
standard requires the math functions to complete without any "externally
visible exceptional conditions". I am still of the opinion that it is
best to prevent the math functions from either raising signals or
setting exception bits in the FPU status register, because they can
crash a program and prevent recovery.
On the other hand, in the comp.std.c archives one person noted that
errno was very inefficient on some processors, and that the C committee
wanted to have another mechanism for trapping errors, so they included
the exception mechanism in C99. (The errno mechanism is now optional,
and there are macros in a header file to indicate whether it works or
not.) Fortunately, we only have the Intel platform to deal with. In
coding the math functions several years ago, I saw that there was a
certain inefficiency involved in identifying error conditions, but it
was possible to bias the tests in favor of quick fall-through for normal
arguments, so that the time hit was only about 10%.
-Eric Rudd
rudd AT cyberoptics DOT com
- Raw text -