Date: Thu, 28 Aug 2003 18:33:46 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: Eric Rudd Message-Id: <9003-Thu28Aug2003183345+0300-eliz@elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <3F4E1401.1020602@cyberoptics.com> (message from Eric Rudd on Thu, 28 Aug 2003 09:38:57 -0500) Subject: Re: Arithmetic Exceptions in C99 References: <200308272025 DOT h7RKPrFT003625 AT speedy DOT ludd DOT luth DOT se> <3F4E1401 DOT 1020602 AT cyberoptics DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Thu, 28 Aug 2003 09:38:57 -0500 > From: Eric Rudd > > 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.