Mail Archives: djgpp-workers/2003/08/28/11:34:47
> Date: Thu, 28 Aug 2003 09:38:57 -0500
> From: Eric Rudd <rudd AT cyberoptics DOT com>
>
> There is good reason not to "generate externally visible exceptional
> conditions", since they might make error recovery impossible. The notion
> -- which I tried to follow in my libc math functions -- was that no
> matter what argument you fed to them, they would come back with some
> result, possibly setting errno. For instance, if you call atan2(0., 0.),
> it tests for that special case, returns with NaN, and sets errno to
> EDOM. If this were not done, an actual attempted division by zero might
> well crash the program (depending on the FPU exception mask in the
> control word), preventing recovery.
I'd like to add that the previos C89 standard actually _required_ such
behavior, albeit indirectly: unless we suppress the SIGFPE generation,
there's no way we could set errno to a suitable value, since the flow
of control never gets to the code that sets errno.
It is also my personal opinion that generating FP exceptions is a Bad
Thing, especially on platforms supported by DJGPP. In particular, all
the versions of Windows that are descendants of the NT family (that
is, almost all of them), misbehave badly if you try to catch SIGFPE.
At least that's how things were when I last looked at this.
> Part of the problem is that C99 never satisfactorily defines
> "exception". Reading between the lines in footnote 178 in clause 7.6.2.2
> (bear in mind that the footnotes are informative, not normative), it
> appears that "exception" is intended to be an FPU processor exception,
> as described by Intel, but I've searched in vain for a normative
> definition. Of course, C99 can't talk about processor specifics; it
> would instead talk of the consequences of the exception visible to the
> program.
It might be a good idea to see what does glibc do on GNU/Linux
systems. If one runs a program there that calls asin(2.0), what
happens? Does it crash? does it raise SIGFPE? can you catch the
signal? something else?
> The material in Annex F needs to be implemented only if __STDC_IEC_559__
> is defined.
Does glibc define this in any of its headers?
> Whether it is worthwhile (or even desirable) to re-write the existing
> math routines to comply with IEC 60559/Annex F is another matter
> entirely.
I'd say we cannot afford such a massive rewrite. Neither libc.a nor
libm.a, as we have them, don't produce SIGFPE; on the contrary, they
go to great lengths to avoid that.
- Raw text -