Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3F4E83A1.44F9EC13@phekda.freeserve.co.uk> Date: Thu, 28 Aug 2003 23:35:13 +0100 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com CC: Eric Rudd 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> <9003-Thu28Aug2003183345+0300-eliz AT elta DOT co DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Eli Zaretskii wrote: > > > Date: Thu, 28 Aug 2003 09:38:57 -0500 > > From: Eric Rudd [snip] > > 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? Below is what happens on my Redhat Linux 6.2 box. I don't have access to Redhat 8, but someone should test with that too, since it has a newer (i.e.: more C99-ish?) glibc. iolanthe:~/src/tmp =] rpm -q glibc glibc-2.1.3-28 iolanthe:~/src/tmp =] cat t-asin.c #include #include #include int main (void) { printf("%f\n", asin(2.0)); return EXIT_SUCCESS; } iolanthe:~/src/tmp =] gcc -g -Wall -o t-asin t-asin.c -lm iolanthe:~/src/tmp =] ./t-asin nan NB: no SIGFPE. > > 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? Yes. It's defined in , which is one of glibc's headers: iolanthe:~/src/tmp =] find /usr/include -name '*.h' | xargs grep __STDC_IEC_559__ /usr/include/features.h:#define __STDC_IEC_559__ 1 iolanthe:~/src/tmp =] rpm -qf /usr/include/features.h glibc-devel-2.1.3-28 > > 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. I don't think anyone has the time to rewrite the maths library. BTW I think you've got too many negatives above. Should it be: "Neither libc.a nor libm.a, as we have them, produce SIGFPE; on the contrary, they go to great lengths to avoid that." (Think of it as: "libc.a and libm.a don't produce SIGFPE;...") Bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]